TOC

git 分支管理策略

Git Flow

荷兰程序员 Vincent Driessen 提出。

Git Flow

  • master 主干
  • develop 开发分支
  • feature/xxx 功能开发分支(临时)
    基于 develop 创建,开发完成之后:合并到 develop 分支,删除
  • release/xxx 预发布分支(临时)
    基于 develop 创建,测试通过之后:合并到 master 分支,打 tag,合并到 develop 分支,删除
  • hotfix/xxx 功能开发分支(临时)
    基于 master 创建,问题修复之后:合并到 master 分支,打 tag,合并到 develop 分支,删除

特点:基于版本交付

GitHub Flow

GitHub Flow

  1. 从 master 拉分支,提交,推送
  2. pull request
  3. 评审,测试
  4. merge 到 master

特点:基本不涉及项目的分支管理,主要是对多人协作方式提出建议:Pull Request。适合多人参与的开源项目,由项目管理员负责维护主干。

中间可以借助自动化工具来静态分析、部署、测试,提升开发速度。但这些工具不是 GitHub Flow 专有,或者说不是它的特色。

这套逻辑看似非常简单,但要硬套到企业项目开发流程中可能会非常复杂,水土不服。
PS: 虽然 git 新增了一个 request-pull 子命令,但可能很鸡肋,不可能脱离 Web 来参与讨论、评审代码。

GitLab Flow

GitLab Flow

分不同环境:

  • master 开发分支,管理方式就是 GitHub Flow,不过就是 Pull Request 改名为了 Merge Request
  • pre-production 预发布分支,只能从 master 合并
  • production 发布分支,只能从 pre-production 合并

如果需要发布:

  1. 从 master 拉分支,比如:20-04-stable,创建语义化版本号。
  2. 如果后期有严重 BUG,可以从 master cherry-pick 过来。

特点:比 GitHub Flow 更进一步,对项目的发布和部署提出了建议,并支持多个环境。

主要是其中有一点特别好的就是: Upstream First, 上游优先。所有环境以及维护分支的提交必须来自 master 分支。

我的思考

当然,还是那句老话:适合自己的就是最好的。
项目分支管理流程要和项目自身的特点,以及团队成员的技术水平相匹配。

Git Flow 的整套流程挺完备的,符合一般开发的习惯,只是对其作出规范而已。
GitHub Flow 也好,GitLab Flow 也好,都可以看做是 Git Flow 的补充。

GitHub Flow 和 GitLab Flow 都假定 master 分支是可发布的,而 Git Flow 从 master 拆分出了一个 develop 作为缓冲,我认为这个设计比较合理。

Git Flow 有几个需要注意的问题:

  1. 合并的时候保留之前的合并记录,谨慎快进 (--no-ff)
  2. hotfix, release 分支推送到 master 发布之后,切记还要同步推送到 develop 分支
  3. 必须坚持 master, develop 上不随意推送(还是得靠 Pull Request 机制)
  4. 如果有不属于当前发布周期需要的开发,不要合并到 develop
  5. 临时分支必须快用快销,不要长时间保留,且合并之后理解删除

我设想中的开发流程

1,基本参照 Git Flow (借助工具)

上游优先原则:master 分支作为所有可发布环境的上游

2,自动化测试:

  • develop, release, master: 只要有变更就触发一次自动化测试
  • 此外, master 应该保持一定频率的定时自动化测试

3,老版本需要维护就在 tag 上拉分支。

现实场景中,可能要为 abc 环境上的某个老版本 v1.0.0 修复 BUG、加功能,或对已有功能进行一些调整。

git branch maintain/abc v1.0.0 # 一旦分叉,就需要长期保留该分支
# maintain/abc/develop
# maintain/abc/feature/xxx
# maintain/abc/hotfix/xxx
# maintain/abc/release/xxx
# 视情况,可以简化处理,不用上面这些分支

PS: 最后需要重新发布的时候可以对版本号加上附加的标识 v1.0.0.1.abc

5,如果是 OEM,针对客户有关的信息、资源应该留给打包系统来统一处理

此外:

  1. 项目应有明确的 roadmap
  2. 代码评审
  3. 数据库设计统一管理
  4. 项目文档,需求库,用例库
  5. 版本号基本上遵循语义化版本规范
  6. 提交记录遵循 git commit message 规范 (借助工具)
  7. CI/CD + 自动化测试

参考资料与拓展阅读