Git分支管理实践

背景

在团队多人协作开发中，分支管理需要解决如下问题：

1. 直到上线并验收通过之前，每个人开发的功能互不影响；


2. 多人开发的功能测试时需要共用同一套（或有限的几套）测试环境；


3. 哪怕代码上线后，也有回滚的可能性，上线回滚不会对主干分支的代码产生影响；


4. 分支管理需要满足快速小步迭代的敏捷开发需求；

我们团队的每个项目有四套环境：
5. 开发环境：开发人员本机或者远程开发环境（我们有几个项目是通过 sftp 远程开发）；
6. 测试环境：供测试人员使用；
7. 预发布环境：类生产环境，上线前的回归测试使用；
8. 生产环境：正式发布功能；

根据实践，我们以 gitflow 为基础设计了自己的分支管理流程，该流程已经实践 2 年了，效果很好。

分支管理流程

说明：

1. 有 4 种分支：feature/fix、test、release、master。


2. feature/fix：开发分支/热修复分支。当需要开发新功能或修复 bug 时，开发人员从最新 master 分支创建新的特性分支，在这些分支上进行开发和自测。格式：feature-主开发人姓名-特性描述，如 feature-songlin-coupon-list。这种分支功能上线后即作废，需不定期清理；


3. test：测试分支。功能开发完成后，开发人员将 feature 分支合并到 test 分支，再将 test 分支发到测试环境供测试人员测试。test 分支属于常驻分支，不过有时候因为操作问题导致污染，需要删掉当前 test 分支，然后从最新 master 创建新的 test 分支（test 重建）；


4. release：功能测试验收完成后，开发人员从最新 master 分支创建 release 分支，按日期命名，格式：release-年月日.当天版本号，如release-20200312.01。将 feature 分支合并到 release 分支，发布到预发布环境给测试验收。预发布验收通过后，将 release 分支发布到生产环境，生产验收成功后将 release 合并到 master 分支。release 也是临时分支，功能上线后即作废；


5. master：常驻分支，上面的代码和生产环境保持一致。feature 和 release 都是从 master 分支创建的。不能在 master 分支上直接开发，正常情况下也不能用 master 分支发版。release 发布到线上并验证通过后，由项目负责人及时合并到 master 上；

释疑：

1. 为何使用 release 分支发版而不是直接发 master？
   主要有两个原因。

   一方面，我们需要保证代码直到在生产验收通过之前都是和 master 隔离的，这样一旦代码有问题，不会污染 master，保证别人从 master 拉的代码一定没问题。

   另一方面，该策略能解决多人发版时对 master 分支的竞用问题。比如张三和李四都要发版（假设张三的发版分支是 release-20200401-01，李四的是 release-20200401-02），他俩协商后让张三先发，于是张三的代码先上预发布回归，不料张三的代码在预发布发现了问题，而且需要较长时间修复，此时就可以直接让李四发，由于张三和李四的发版分支是独立的，互不影响。假设是使用 master 发版，那么张三由于已经将代码合到 master 了，此时对 master 造成了污染，需要回退。

   再考虑另一个场景。张三开发了个大功能，现在正在预发布回归，预计要两天时间，此时线上突然出现了个紧急 bug 需要修复，由于张三的代码没有合到 master 上，李四就可以放心地从 master 拉 fix 分支去修复 bug，并插队作紧急上线。

   
   



2. 虽然 release 能解决并行发版问题，但可能会带来发版覆盖问题，如何解决？
   由于代码直到上线并验收通过前都不会合并到 master 上，理论上会出现某人的发版忘记合到 master 上而导致后面的发版把前面的代码覆盖掉的情况。

   实践中我们是通过管理手段来规避这种情况发生的。

   首先，这种模式比较适合小团队（10 人左右），大团队需要划分小组管理。

   我们团队的开发和发版都是有严格规范和审批流程的，开发人员要上生产的时候需要邮件申请，由团队负责人审批。团队负责人一般要做最终代码审核，其中重要的一项就是分支正确性检查（这些工作可能是和项目负责人共同完成的）。另外每个项目都有具体的项目负责人，当有新功能上线并验收通过后，由项目负责人将发版分支合并到 master 分支，并通知团队中各成员，后面发版的需要同步 master 上的最新代码。

   比如前面说的张三和李四的情况，当李四的代码（release-20200401-02）最终合并到 master 上后，张三需要将最新的 master 合到他自己的发版分支上（release-20200401-01），并重新申请预发布回归。