团队中的 Git 分支

前提

相对固定的发布周期/迭代周期
做好项目的版本计划

如果没有规律的迭代周期和可靠的版本计划，即使我们的 Git 分支模型再强大，开发团队也免不了焦头烂额。

分支模型

master：受保护分支，不允许开发人员直接 commit，且随时可发布生产环境。
develop：只有本迭代相关代码、在开发完成以后才能通过以提交 PR 的形式、申请 merge 回 develop 分支。develop 分支用于发布测试环境。
feature：一旦初始版本上线以后，所有功能开发必须在 feature 分支上进行开发，用完即删，包括对应的远程分支。
hotfix：如果线上发现严重 Bug、需要紧急修复，这时从 master 分支检出 hotfix 分支、进行 Bug 修复工作。

初始版本上线了

给 master 分支打 tag

$ git checkout master
$ git tag -a 1.0.0

从 master 分支创建 develop 分支

$ git checkout -b develop master

进行新功能开发

假设有4个新功能需要开发：

属于当前迭代的： F1、F2（新功能）和 FF3(Bug修复)
迭代不确定的：UF4

开发个人从 develop 分支创建 Feature 分支进行开发：

$ git checkout -b feature-f1 develop
$ git checkout -b feature-f2 develop
$ git checkout -b feature-ff3 develop
$ git checkout -b feature-uf4 develop

属于当前迭代的新功能开发完成后

开发个人切换至本地 develop 分支，pull 最新代码：

$ git checkout develop
$ git pull

开发个人切换至相关 Feature 分支，merge develop 分支的最新代码：

$ git checkout feature-f1
$ git merge --no-ff develop

merge 完成、自测通过后，开发个人向 develop 分支发起一个 PR/MR 请求，申请 Code Review，指定相关人员。

处理 PR/MR

在收到 PR/MR 后，相关人员需要及时完成 Code Review，如有问题需要开发个人进行相关调整。

确认无误后（代码 OK、版本计划没有变动），相关人员接受 PR/MR、将 feature-f1 merge 回 develop 分支。

signoff 需要在 PR/MR 在对话列表中体现，作为 Code Review 的凭证。（由于 develop 不是保护分支，在接收到 signoff 后，也可以由开发个人自行接受 PR/MR、完成 merge）

发布测试

merge 完成后，通知测试人员feature-f1功能已实现、可以发布测试环境，最终由测试人员决定何时发布测试。

TODO：结合 GitHooks 自动触发 Jenkins 发布测试环境

此时线上发现严重 Bug

开发个人 从 master 分支检出 Hotfix 分支：

$ git checkout master
$ git pull
$ git checkout -b hotfix-0022

必要时需要为 Hotfix 分支提供独立的持续集成环境（CI 任务、主机、Web 容器、数据库实例等）。

Bug 修复成功后，开发个人向 master 和 develop 分支发起 PR/MR 请求代码合并，同时指定相关人员。

相关人员完成 PR/MR 的处理，将修复代码 merge 回 master 和 develop 分支，通知发布人员发布生产。

发布生产以后，通知相关人员开始必要的验证工作。

当前迭代已开发测试完毕，准备发布生产

相关人员将 develop 代码 merge 回 master 分支，通知发布人员发布生产：

$ git checkout develop
$ git pull
$ git checkout master
$ git merge --no-ff develop
$ ./bump-version.sh 1.2.0
version bumped to 1.2.0
$ git tag -a 1.2.0

TODO：结合 GitHooks 自动触发 Jenkins 发布生产环境

生产发布完成后，属于下一迭代的 Feature 分支才可以向 develop 分支合并

必要时，需要为跨迭代的 Feature 分支提供独立的持续集成环境。

FAQ

......

mambat / blog