实战Git分支策略

(1) 主干开发，发现代码质量不强，导致代码提交后阻塞，等待修复问题。
(2)QA 进入了在 Dev 环境对应 Master 分支，由于 Dev 环境一直在合并代码，QA不得不停下来，因为服务有一段时间可能持续在部署。

上述问题就会让我们思考应该如何让我们的分支管理对团队更加有效。

在常见的分支策略上，有的分支策略是指看上去挺有帮助，但是实际操作过程中并不利于团队提升效率和改进。

常见的三种分支策略：Git Flow、Github Flow、TBD。对于三种常用的分支策略，可以按照下面的思路进行选择。

Git Flow 并不是Git上的最佳实践。虽然 Git Flow 是基于 Git 功能构建的软件开发工作流。

Git Flow 模型是什么？

Git Flow 让开发过程基于不同的分支。

Master Branch: Master 分支上的代码可以随时部署到 Master 上。

Feature Branch: 每个特性在一个单独的 Feature 分支上进行开发，开发完成后 merge 到 develop branch 上进行集成。

Develop Branch: 用来集成的分支，当功能达到稳定后，可以 merge 到 master 分支

Release Branch: 为每次发布准备 realse 版本，在这个分支上，只进行Bug Fix，并在完成后 merge 回到 master 和 develop 分支。

Hotfix Branch: 用于快速修复，在修复完成后merge 到 master 和 develop 分支上。

通过这些分支 Git Flow 制定了一套开发、集成、部署的流程。看上去很好，不同的分支担任不同的责任。但是时间中它的不好确实超过的它的好。

那么它的问题在哪里呢？

（1）开发一个新的 Feature 就需要创建一个新的 Branch；

（2）当看文字是觉得它简单，但是离开文字之后，很多开发者并不清楚哪个环节应该怎么操作；

（3）Feature 分支阻碍了Merge，Merge 代码总是很痛苦的，因为很容易出错，而且较大的一次 Merge 成本会非常高；

（4）Feature 需要开发完成后才能 merge 到 develop 分支，无法做到持续集成。

IDE 做了很多改进帮助 Dev 降低 Merge 成本。但是对于业务逻辑上的 Merge IDE 是无法帮助 Dev 完成的。

在软件的世界里，如果一件事很痛苦，我们就频繁的去做它。比如集成很痛苦，我们就持续集成。Merge 很痛苦我们就频繁的 Merge。

显然 Git Flow 这种分支策略没有办法让我们频繁的 merge。

采用 TBD 模式开发的时候主要有两个分支：

Master Branch：所有 Dev 在 Master 分支上进行开发。

Release Branch：Release 分支，当一个解决过去，从 Master 分支拉出 Release 分支。

我们需要的只是多个环境：DEV、SIT、UAT、PROD。团队代码质量高，可以可以直接使用上面四个环境，如果团队代码质量不高，可以为 QA 准备一个 Test 环境。

（1）如果遇到需要创建 Release 但是功能尚未开发完成怎么办？

使用 Feature Toggle 功能，控制开边的避开闭，当然使用 Feature Toggle 也是有成本的，除了添加 Toggle，还需要维护这些 Toggle。

（2）当发现 BUG 怎么办？

当 Release 分支发现 Bug 的时候，可以直接在 Release 分支上进行修改，修改完成后 merge 回到 master；也可以在 master 分支上进行修改，修改完成后 cherry-pick 到 Release 分支。

（3）当 DEV 环境不稳定怎么办？

临时做法就是创建一个 Test 环境，可以选择定期自动部署到 Test 环境，也可 QA 根据需要手动更新 Test 环境。

根本做法是提升工程质量。在项目管理时间上和项目技术时间上需要同时改进。可以通过 Check Style + PMD + Jacoco 在 Dev 本地就运行测试，测试通过后才可push（PS：使用git hook来限制一下）。同时团队可以选择使用 Arch Unit 来守护架构。

当然上面技术的改进的前提是团队需要些测试，否则持续集成只能叫做 "人肉持续集成"。

Github Flow 是一个成本较高的分支策略。

Github Flow 需要对每一个分支创建一个运行环境，来验证分支的正确性，这就需要 Ops 提供相应的环境才可以。但是它未解决 merge 时的验证提供了保证。

对 Github Flow 感兴趣的可以移步到这里：《Github-Flow》。不过我不认为它是真正敏捷的工作流，因为它是建立在一定条件基础上的。

所以如果你的团队是个小型团队，可以绕过了，如果是个大型团队，团队能力又好，说不定这个 Github Flow 会适合你。