个人技术分享

git 分支管理总结

# git 分支管理总结

# 介绍

  • 一般来讲，开发环境可以分为四种类型，分别为：
  • dev : Development environment，开发环境，用于开发者调试使用。
  • fat: Feature Acceptance Test environment，功能验收测试环境，用于软件测试者测试使用。
  • uat: User Acceptance Test environment，用户验收测试环境，用于生产环境下的软件测试者测试使用，也就是常说的预发环境。
  • grey: 灰度环境，对应可控的小部分生产环境，一般大公司会有灰度发布过程，中小创业公司可以酌情落地。
  • pro: Production environment，生产环境。

# 常用分类

  • 根据现阶段的状况，目前一共配置了三套环境，分别为 dev，fat 和 pro
  • 对应的分支按照环境区分，分为 dev【开发】，fat【测试】，master（用 pro 也可以）【生产】三个分支。
  • 开发分支，用于开发环境功能部署，主要给开发人员联调，自测使用。
  • 测试分支，用于产品、运营、测试及开发同学功能测试、验收、提bug
  • 生产分支，对应正式线上版本。
  • 补充：其实还应该有个预发布分支，现阶段还没有用上。

# 开发流程

  • 1.以一个敏捷开发迭代周期为例，从 master 分支新建 feature 分支，比如班车v1.0.0的直播功能迭代，可以命名为 【迭代名称 + 班车版本号】，即：创建分支 feature/live_v1.0.0
  • 2.然后在 feature 分支上完成对应功能开发，联调完成后，提交 feature/live_v1.0.0 到 dev 分支的 merge request，由项目 maintainer 负责 merge ，并进行 dev 分支部署。由前后端开发人员自测功能。
    • 如果v1.0.0班车还有其他的feature，则从 master 再创建一个新的 feature 分支，比如登录功能，可以创建分支： feature/login_v1.0.0
  • 3.dev 联调、自测完成后，提交班车相关的 feature 分支到 fat 分支的 merge request，由项目 owner 负责 merge 和 代码 review，并进行 fat 分支部署。通知产品、测试、UI进行测试和验收。如果有bug，则在 feature 分支上进行修改、修复，并重新执行 2、3步骤，直至功能验收通过。
    1. fat 验收通过后，则可认为这个版本的功能测试验收完成，可以直接提 fat 到 master 的 merge request ，由项目 maintainer 来执行。
    1. 将 master 分支部署到生产环境。
    1. 打 tag，并周知项目成员，删除本地、远程冗余分支。
    • git tag -d tagName 删除本地tag
    • git push origin :refs/tags/tagName 删除远程tag
    • git tag -a v1.x.x -m 'tag 描述' 打tag (tagName 前面记得加v)
    • git push origin tagName 推送到远程
    • git remote prune origin 清理无效的远程追踪分支

# hotfix 流程

  • 考虑到修复线上问题的紧急性，直接从当前 master 分支创建 hotfix 分支，比如修复直播问题，命名为 hotfix/live。根据情况来判断是否需要经过 fat 环境验证，如果是小问题，可本地测试通过后，直接合并到master，快速修复。

# commit 规范

  • feat: 增加新功能
  • fix: 修复bug
  • docs: 只改动了文档相关的内容
  • style: 不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
  • build: 构造工具的或者外部依赖的改动，例如webpack，npm
  • refactor: 代码重构