Git 分支管理实践

背景

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

  1. 直到上线并验收通过之前,每个人开发的功能互不影响;
  2. 多人开发的功能测试时需要共用同一套(或有限的几套)测试环境;
  3. 哪怕代码上线后,也有回滚的可能性,上线回滚不会对主干分支的代码产生影响;
  4. 分支管理需要满足快速小步迭代的敏捷开发需求;

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

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

分支管理流程

Git 分支管理实践_第1张图片
说明:

  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),并重新申请预发布回归。

相关
请参照我的另一篇技术团队开发与发版规范

你可能感兴趣的:(团队协作,敏捷开发,项目管理,git)