一个迅速的 git 分支模型

背景

目前已有的主流模型，不能完全符合我们对于多人研发合作，和多功能同时研发的需求。
所以我们提出了符合我们自己分支模型。

目前市面常见的分支模型有：

git flow

• git flow 流程繁琐，研发、测试最后到上线，期间需要多次合并分支。
• 由于 develop 是长期分支，可能留有测试完毕但是未上线功能。如果基于 develop 分支创建新的功能分支，那么新功能必须晚于当前 develop 未上线功能上线。不符合目前需求多变的大环境。
• 测试阶段和预发布环境，需要拉新的分支构建，使得两次构建产物可能不同，降低了前期的测试回归意义。

trunkbase

• 门槛太高，我们很难保证每个人单次提交不破坏构建。
• 我们没有特性开关平台。
• 多人开发时，主干的 npm 的依赖版本难以锁定，创建发布分支时成本太高。

我们参考了主流的模型，结合我们自己的经验，确定了下面的分支策略。

原则

• 稳定
• 迅速

设计思路

1. 减少长期分支数量：因为只要有长期分支，就可能存在测试通过，正在等待上线的特性，会阻碍其他特性上线。
2. 减少分支合并次数。
3. 滞后合并到主干：这样保证了主干不会有没上线的特性。

约定

1. 只有一个长期分支，以下以 master 代指。
2. 所有特性分支，从最新 master 直接拉取。
3. 特性分支创建以后，直接研发、测试、上线。
4. 特性分支上线后，再合并回 master，然后删除。
5. fix 在 master 更改，直接研发、测试、上线。

优点

1. 上线后再合入 master，保证了 master 完全稳定。
2. 多个环境只需一次构建，保证上线代码和测试代码完全一致。
3. fix 迅速，只需要在 master 直接修改发布。
4. 上手快，只需要基于最新 master 创建分支即可。
5. 功能分支之间彼此隔离。

缺点

1. 需要关注是否将 master 合并到当前特性分支。
2. 需要关注是否将上线后的特性分支合并到 master。
3. 需要额外创建 code review。
4. 多功能同时开发时彼此隔离，无法保证兼容性。

PS. 以上缺点的对策

1. 使用自动化工具，完成 master 和特性分支的相互合并。
2. 特性分支创建以后，同步发起特性分支到 master 的 MR。由于 gitlab 的 MR 自动跟踪分支变更，可以在后续任意时间进行 code review。
3. 功能分支研发过程中如果合并了新的 master 内容，要在功能分支重新回归。