Git Flow 的另一种思路

Master 分支 下文简称（M)
Test 分支 下文简称 (T)
Feature 分支 下文简称（F）
Hotfix 分支 下文简称（H）
Merge Request 操作请求 下文简称（MR）

高度精简为一句话：一切分支都从Master分支中拉出！

迭代开始

暂定当前迭代为Vn，则上一个稳定迭代的版本为Vn-1。

首先从M -> T，作为开发过程中的测试分支。

根据产品文档等需求划分工具提示，每一位同志按照自己手头的工作进行:

M -> F1
M -> F2
...
M -> Fn

然后根据各自的时间安排进行开发

迭代进行时

流程：

M -> F (F' F'' ...) -> T

正常迭代开发测试合并

同志张三正在进行自己的F3功能需求开发，那么他每天需要：

1. 是否为协同开发？是=>2，否=>3
2. 拉取远程分支的代码到本地，处理同伴开发可能导致的冲突；
3. 进行本地开发、测试；
4. 下班前在本地暂存修改，做好commit记录提交到远程仓库；
5. 在仓库中发起MR，指定对应的Code Review对象为assignee，如果该需求正在开发过程中，则需要点击
   之后就会变成
   提交之后可以方便Code Review的同志今天代码检查；
   如果已经开发完成确保可以合并，那么可以在MR中点击Remove the WIP: prefix from the title...，这样在代码检查完毕之后便可以合并到对应的T中了。

发生了conflict!

M -> F3 -> T

M -> F4 -> T 

// 此时F3和F4中都对 FileA 进行了修改 发生了冲突

同志张三和同志李四在各自的F中都对同一个文件进行了修改，因此在合并到T时发生了冲突；

解决方案：

1. 发现产生冲突的同志，在完成Code Review后，将T拉到本地后，进行冲突解决，再提交T；（推荐）

   origin/T -> T
   F4 -> T (fix conflict)
   T -> origin/T

2. 发现产生冲突的同志，在完成Code Review后，从M -> F(3+4)，然后联合与自己产生冲突的同学把各自的F合并到F(3+4)中；（避免在最后每个人把各自的F合并到M的时候再解决一次冲突，但是有可能产生很多F（n+m），慎用）

   M -> F(3+4)
   F3 -> F(3+4)
   F4 -> F(3+4)
   F(3+4) -> origin/F(3+4) -> T

迭代结束

现在迭代完成了，需要把所有的F分支合并到M上面进行发布上线操作；

常规状态

在确保T的测试充足情况下是可以直接合并到M的，而且这种时候几乎不会产生任何冲突，平滑合并上线。

<!-- 方案1 -->
T -> M
// 等于
<!-- 方案2 -->
F1 -> M
F2 -> M
...
Fn -> M

突发情况

“由于xx功能考虑不周，本次迭代不上了”——产品经理
“我还想在XX功能上面增加亿点点东西……”——产品经理

在某些情况下会出现Fn这个功能需求无法上线的情况，这个时候需要：

1. 各自合并:

F1 -> M
F2 -> M
...
Fn-1 -> M
// Fn 不合并
// 在master上面解决一下冲突，如果master受到保护，则需要看方案2

1. 拉取一个新的T2，把除了不上线的需求都合入其中，进行回归测试后合入M

M -> T2
F1 -> T2
F2 -> T2
...
Fn-1 -> T2

T2 -> M

发现历史bug

历史bug为在 上线的版本中发现的功能上的缺陷，需要及时地进行修改；

M -> H -> T // 进行测试

H -> M // 测试完成后可以快速上线