Git workflow 选型分析

前言

「A successful Git branching model」 这篇文章，应该是我第一次真正开始从 workflow 的层次来思考和看待 git 的使用问题。

而实际根据文章中提到的 「gitflow」 来进行实际项目代码演进的时候，发现无法完全契合我们的实际需要。综合陆续对 git 的各种主流 workflow 的了解。提炼出一点：没有万能的 workflow，只有最适合的 workflow。

而这篇文章，就是来讨论一下如何挑选、使用、优化项目的 git workflow。

原则

在对 git workflow 进行调研的过程中，「Git Workflows That Work」这篇文章让我产生了一些启发。特别是其中他提到的选择 workflow 的 guildelines ，我认为可以作为我们针对自己身实际需求进行 git workflow 设计的准则。特此引用并翻译如下：

• Branches should be used to represent a single deliverable request from the business- like a single user story or bug fix. Something that can be approved by the business that contains everything needed for that single request to be released- and nothing more!

  「Branch 仅用于唯一且独立的需求。」

  每一个分支必须单独代表一个来自需求侧的可发布内容，比如一个 userstory 或者 缺陷修复。这个来自需求侧的可发布内容内容，包含了且只能包含所有这次发布所需要的东西。

  这条强调了 branch 的独立性、完整性，以及 branch 的开发目标的唯一性。

• The longer a feature branch lives without getting merged in for a release, the greater risk for merge conflicts and challenges for deployment. Short lived branches merge and deploy cleaner.

  「一个分支 merge 到 release 时间越早越好。」

  一个功能分支过于长时间的独立维护，而不合并到 release 分支中，会对开发者带来极大的风险和挑战。开发周期短的分支，会有更简洁清晰的合并以及发布。

  这里提到的风险，意味着合并冲突出现概率、以及回归测试范围。

• Business owner involvement in your workflow is essential. Don’t merge, don’t deploy, don’t work without their input. Otherwise pain and tears will ensue (or worse).

  「万物由需求而生」

  Business owner 必须要参与到你的 workflow 中来，不要在没有需求的时候做合并，发布和其他工作。不然接踵而至的必然是血和泪。

  这段描述的有点奇怪，但是可以理解为不要做没用处的事情，开发过程一定是由需求来指导的，所以没有需要，不要动代码。比如说你的分支都是以需求名称命名，或者发布版本命名，而merge，必然代表着这些需求或者版本的完成和上线。

• Avoid reverts. Test, test, test your branch before a merge. When merging use git merge –no-ff, which will ease merge reverts if really needed.

  「避免 revert 。」

  避免 revert 。在 merge 之前，记得在你的分支上测试！测试！测试。不过使用 git merge --no-ff 命令来完成 merge 操作，将会让你在实在需要进行 revert 操作的时候更简单。

  关于git merge --no-ff 命令，看这里

• Your workflow should fit how you release. Do you release continually, multiple times a day? Do you have 2 week sprints with completed work to release on a regular schedule? Do you have a business Change Control Board where all released items must get reviewed and approved first? Does someone else run your releases, like the Operations team or a Release manager? Your branching and merging strategy needs to make releasing easier.

  「根据发布流程选择 workflow」

  你的 workflow 需要适合你的发布方式。考虑你是否每天都会多次、持续的进行集成发布？你是否采用了2周的 sprints 周期来完成你的需求，并统一发布？你是否有一个需求管理面板，并且要求所有的发布内容必须经过管理面板上的 review 和 批准？你的发布类容是否被其他人引用，比如配置管理团队或者发布管理团队？你的分支拉取和合并策略必须使你的发布工作更加容易，而不是更难。

  同样的，对于产品的发布环境，是否有完善的 testcase ，充分自动化的测试平台和工具，以及明确的验收标准。决定了发布的成本。在发布成本较高的时候，不要因为你的workflow ，导致平白多出不需要的发布次数。

• Complicated workflows drive people crazy. Make it simple. Review your workflow and ask how you can simplify it. In actively making things more simple, you will also make them easier to understand and work with as well as easier for others to adopt and maintain.

  「越简单越好」

  复杂的 workflow 会让每个人抓狂。经常回顾和总结现有的 workflow ，找到让它更简单的方法。实际上，workflow 越简单，越容易被大家理解，从而长期保持下去。

  举个简单的例子，release 分支完成了测试，为什么非要 merge 到 master 分支上再 deploy 。如果没有为什么，是否可以直接在 deploy 分支上发布？

正确选择 workflow

如何正确选择 workflow 是我目前也在研究的内容，暂时还没有类似于 「选择 workflow 的黄金法则」之类的结论出来。不过可以先看看我们能了解到的不同 workflow 对应于不同情况的优缺点分析。

github workflow

github 大家都用过，他的这个工作流程典型特征是大家都直接从 master 分支拉取一个 feature 分支，开发完了以后，直接merge回 master 分支。这个比在「A successful Git branching model」 中提到的流程要简单太多。

使用这个模式的问题，就是如何保证 master 分支上的内容的可发布性和可测试性。由于没有专门的 develop 分支进行功能分支合并，没有专门的 release 分支进行测试验收，所以 master 分支上很容易出现无法发布的临时产物。

所以当使用这个 workflow 的时候，团队必然需要具备这样的条件：

1. 各个feature 之间的修改内容的高度不相关性。这样合并的时候才能有较低的冲突概率。
2. 高覆盖率的测试工具，这样能在 feature 分支合并之前完成功能验收，保证合并之后的缺陷率。
3. 高效的测试回归流程，这里可以通过持续集成工具上部署高自动化测试流程将merge 操作和回归测试自动化的完成，从而保证每次merge 操作都能快速的完成回归测试。保证 master 分支上的可用性。

在这种模式的启发下，可以考虑使用 rebase 命令来代替 merge 命令，从而时你的 git 记录就像 master only workflow 一样干净整洁。

你可能会记得：永远不要用 rebase 这个建议。但是只要你理解 rebase 的含义，也是可以用的。关于 rebase ，我觉得这篇文章写的挺好的。

Skullcandy’s workflow

这里不深入探讨 skullcandy 这家公司是具体做什么的了，简单看一下这个 workflow 也是一个比较有代表性的模型。

在这种 workflow 中，通过 QA branch 这个分支，一定程度降低了在 github workflow 中，对验证、测试回归的工具和工作流的要求，在这个分之中，将开发人员和测试等其他验收人员的职责通过 branch 做了划分，从而测试人员只需要在 QA branch 上做验收测试，并且由于 QA branch 分支的合并节奏是可以控制的，所以可以根据发布周期来控制 QA branch 分支上的合并时机。

这种 workflow 应该说比较适合敏捷开发过程中固定周期的发布行为。通过固定的敏捷周期来约定 QA branch 的同步时间。

这种 workflow 的坏处，由于无法第一时间快速的 将 freature branche 上的内容进行合并，验收。这样会带来后续更高的代码冲突概率和更迟的缺陷修复时间。

master only workflow

这个workflow 比 github workflow 更进一步。但是对测试、发布的要求奇高。

过去我竟在个人独立项目中使用这样的 workflow 进行开发，自然这种情况下我是不需要回归测试、发布等流程的。

另外 stackworkflow 上的这个答案中提到的建议，也说明了使用分支的优势。