特性分支仍然(或曾经)被认为是一种糟糕的实践吗？

Question

我来自TFS世界，刚刚适应了Git，我打算向我的团队建议，我们应该合并Gitflow工作流，正如文森特·德雷森的著名文章未来所指出的那样。

几乎所有关于分支策略的现代文献都表达了Gitflow工作流的有效性，Gitflow工作流是特性分支的扩展版本，但来自Martin Fowler的专题文章分支文章(2009年)等有影响力的工程师的文章使特性分支在总体上失去了信誉，支持持续集成。

他的一些批评者说Fowler反对特性分支部分是因为他使用SVN作为他的VCS，这是合并的一个无效工具，因此导致Fowler推荐一个分支反模式“合并偏执狂”。

福勒随后于2011年在通过说DVCS系统可以使合并更容易，但它们仍然不能解决语义冲突。做出回应。现在，在2014年，我们有了语义合并这样的具有语言感知能力的合并工具，这些工具可能完全解决了这个问题。

我的问题是

1. 是特性分支和连续集成，互斥？
2. ：Fowler的文章在现代开发中有多重要，特别是我们可以访问诸如SourceTree、Git、Jenkins和其他代码审查软件的工具，这些工具使得特性分支和类似的功能变得更容易？

Answer 1

根据我的经验，这取决于您的特性分支是在哪里创建的。如果您遵循的是一个叉和合并模型，在这个模型上创建了特性分支，那么我没有看到任何问题。从主项目的角度来看，它仍然只是一个(主线)分支；特性分支出现的唯一位置是在您的分叉中，使用它们的唯一原因是将您提交的更改(以拉请求的形式)与主分支隔离开来。

Answer 2

如果您查看维基百科关于持续集成的文章(今天)，您将看到它是关于每天与单个主线合并的。基于此，我会说你的第一个问题的答案是肯定的，但这并不排除使用特性分支策略。

对于你的问题，第二，我不认为答案是那么直截了当，但根据我的经验，创建分支很容易，在熵之后合并它们就不是那么简单了。我仍然认为福勒的文章是准确的。

Answer 3

1. 不，您可以在主线和每个特性分支上设置CI没有问题。
2. 它仍然是非常相关的。虽然自动合并算法越来越好，包括一些基于语义的合并，但计算机仍然不可能推断出它的含义。在我们得到真正的计算机智能之前，这仍然是个问题。问题是，自动合并产生不正确结果的百分比是多少，知道会产生错误结果的情况的百分比是多少。本质上，如果您能够自动推断出自动合并将失败的所有情况，您将能够将这些情况路由到人类。但这也是一个很难解决的问题。最糟糕的情况不是自动合并不能合并代码，而是当它可以合并代码时，而是合并错误--通常是在语义上，或者在没有人工洞察力的情况下，导致种族状况或其他难以识别的问题。

一般来说，特性分支对于隔离一个小团队中的更改非常有用，在这个团队中，如果您对某个特性的质量不确定，代码可能会对其他在项目中工作的较大团队产生不利影响，或者您不确定该特性是否会进入下一个版本。

您希望将功能分支的使用限制在尽可能短的时间内。具有复杂变化集的两个分支之间的合并代码可能比较困难，需要很长的时间，这一困难增加了o(n)以上，而n是两个分支上的变化之和。一般来说，超过一个月，你必须有一个非常好的源代码控制系统，良好的代码接口/体系结构，或OCD开发人员或三者的结合。

项目中大约25%的时间用于减少技术债务，这主要包括代码重构。特性分支是重构过程中的一个问题，因为重构前和重构后分支的合并可能非常困难。出于这个原因，您希望在开始重构之前确保所有功能分支都被合并。