今天读到了一篇文章《Gitflow有害论》， 虽然文章的标题有点极端，但是其中的观点还是很有价值的。结合工作中使用git的一些感想，谈一谈我对于使用git的workflow的一些想法。

Gitflow

在这篇文章之前并没有认真的看过Gitflow的整个流程，一开始使用git的时候看到过这个流程，但是由于过于复杂而且大家对git都不大熟悉，所以没有采用这个流程。

从我个人的经验来看这个Gitflow，有下面几个很明显的坑。

1. 某一些feature分支的时间跨度太大，这会导致一个很严重的问题就是当这个feature分支回到develop的时候可能会产生很多冲突。而且这些冲突可能涉及到业务逻辑层面，需要额外的工作量去fix。而且这个过程往往很纠结且容易出错。2.
2. feature时间跨度太大的另一个坏处就是pull request会变得很大，一个很大的pull request往往会让review的人很头疼。很容易让代码review的人忽略其中隐藏的一些问题。

除了这两个比较大的坑以外，关于release branch和master branch的分工，我觉得添加了很多工作量和复杂度，但并没有带来明显的好处。

Github 的flow

github的flow其实非常的简单，详见：Understanding the GitHub Flow，GitHub Flow。

从文中可以看出，这个workflow里只有两种分支。一种是master 分支，这个分支是高质量可以随时部署的分支。另一种则是feature分支，即功能开发的分支。开发完以后直接通过Pull Request的形式回到master。

可以看出github的flow非常的简洁明了。但是我觉得采用这种flow有两个大前提：

1. CI能够在Pull Request阶段覆盖大部分的测试案例。

2. 项目必须是类似于github这种web的项目，可以进行频繁的产品部署。并且能够迅速的修复发现的问题。

我认为理想的git workflow

我认为没有一种放之四海而皆准的workflow，一个项目所采用的workflow其实主要取决于组织的文化和产品的特点。

我认为一个好的workflow应该满足一下几个条件：

1. 只有一个master分支，不需要develop分支。
2. 有一个良好的持续集成环境，能够对每一个pull request进行验证，确保其通过所有的测试。
3. feature分支要尽可能的小，如果没办法确实需要做很多改动的话。那么就当完成一部分可以work的代码的时候，发出Pull Request。将这一部分先回到master。这个主要是为了让Pull Request更精简，让代码冲突更早的暴露并解决。
4. 对于客户端的应用，release分支不可避免。拉出release分支的时候如果有一些不需要的功能或未完成的功能通过一些技术（Feature Toggle，Branch by Abstraction）来将其屏蔽。
5. 当release分支中有bug的时候，在master上做修复，并cherry pick到release分支。如果无法cherry pick，则手动修改。
6. release版本后在release分支上打上tag以便日后的hotfix。

我这里提到的这些点跟《Gitflow有害论》文中提到的Trunk Based Development工作流其实有点像。但是我对于这个Trunk Based Development还没有研究透，不敢妄下结论。

文中还提到了一下技术：Feature Toggle，Branch by Abstraction。看了给出的链接，有点粗浅的认识，改天深入的去仔细阅读一些这些技术。