Vincent Driessen’s branch model

我们在使用分支时，一般是使用 Vincent Driessen’s branch model。但是当多个feature分支同时开发，并且包含开发环境、测试环境、预生产环境等多个环境时，会有一些问题。比如：张三开发feature/a分支，李四开发feature/b分支，他们开发都已经进行到测试阶段了，他们的代码已经被合并到develop和test分支。这时我们要把张三开发的功能发布生产环境，按照"Vincent Driessen’s branch model"会把develop分支最终合并到master,但是李四的feature/b也被合并到master分支了，这不是我们所期望的，我们不想发布feature/b分支。

How? New Git branch model.

我们可以使用如下图所示的分支模型。

我们有4个常驻的分支，分别是dev、test、preview、master，对应联调、测试、预生产、生产环境。
当我们开始新的功能开发时，从master分支checkout出feature/a分支。当需要联调时，把feature/a分支合并到dev分支。当需要测试时，把feature/a分支合并到test分支。当需要发布预生产时，把feature/a分支合并到preview分支。当需要发布版本时，把feature/a分支合并到master分支。对于另一个新功能feature/b，它与feature/a类似。

New Git branch model的缺点

由于分支模型的改变，对于一个冲突，New Git branch model可能需要解决多次。

我们把冲突分为两种类型：
1.多人开发同一个分支(比如feature/a分支)时的冲突，这种冲突在我们pull feature/a的时候会解决，只解决一次。
2.多个feature之间的冲突，比如feature/a和feature/b，当我们把feature/a和feature/b合并到dev分支时需要解决冲突；同理当我们把feature/a和feature/b合并到test时也需要解决冲突。

解决方法

首先，对于一个feature的开发更容易产生冲突，不同feature之间产生冲突的可能性是比较小的。当类型2的冲突产生时，我们可以在保证只有冲突分支的不同时，对分支进行dev->test->preview->master的合并。比如：dev分支和test分支是相同的，dev分支合并了feature/a和feature/b，这时如果test分支也需要合并feature/a和feature/b，那么可以从dev分支合并到test分支。