特征分支仍然（或曾经）被认为是一种不好的做法吗？

Question

来自TFS世界，并且刚刚对Git感到满意，我即将向我的团队建议，我们应该按照Gitflow workflow的指示加入famous article by Vincent Dressen。

几乎所有围绕分支策略的现代文献都表达了Gitflow工作流程的有效性，Gitflow工作流程是功能分支的扩展版本，但来自有影响力的工程师的日期文章，如Martin Fowler's Feature Branch article (2009)，在一般情况下使用功能分支失效。支持持续整合。

Some of his critics表示，Fowler对功能分支的反对部分是因为他使用SVN作为他的VCS，这是一种无效的合并工具，因此导致Fowler推荐一种分支反模式“合并偏执狂”。

福勒于2011年回复by saying DVCS systems may make merging easier, but they still don't solve semantic conflicts。现在在2014年，我们拥有语言识别合并工具，例如Semantic Merge，这可能会完全解决这个问题。

我的问题是

1. 功能分支和持续集成是否相互排斥？

2. Fowler在现代开发中的文章有多重要，特别是我们可以访问SourceTree，Git，Jenkins等工具，以及更容易实现功能分支等的代码审查软件？

Answer 1

根据我的经验，这取决于您的功能分支的创建位置。如果您正在遵循fork和merge模型，在fork上创建功能分支，那么我没有看到任何问题。从主要项目的角度来看，它仍然只是一个（主线）分支;功能分支显示的唯一位置在您的分支中，使用它们的唯一原因是将您提交的更改（以拉取请求的形式）与主分支隔离。

Answer 2

如果您查看有关持续集成（今天）的Wikipedia文章，您会看到它是关于每天与单个主线合并的。基于此，我想说第一个问题的答案是肯定的，但这并不妨碍使用特征分支策略。

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

Answer 3

1. 不，您可以在主线和每个功能分支上设置CI，没有问题。

2. 它仍然非常相关。虽然自动合并算法越来越好，包括一些基于语义的合并，但计算机仍然不可能推断出意义。在我们获得真正的计算机智能之前，这仍然是一个问题。问题是，自动合并产生错误结果的情况百分比是多少，以及它知道它会产生错误结果的情况的百分比是多少。从本质上讲，如果您可以自动推断自动合并失败的所有情况，您就可以将这些情况路由到人类。但这也是一个难以解决的问题。最糟糕的情况不是自动合并无法合并代码，而是它可以合并代码，但合并错误 - 通常是语义或导致竞争条件或其他一些在没有人类洞察力的情况下不易识别的问题。

一般来说，功能分支对于隔离一个小团队中的变化非常有用，这个变化适用于您不确定其质量的功能，代码可能会对项目中其他较大的团队产生负面影响，或者您不确定是否功能将进入下一个版本。

您希望将功能分支的使用限制在尽可能少的时间内。在具有复杂变更集的两个分支之间合并代码可能很困难并且需要大量时间，难度比o（n）提高，其中n是两个分支上的变化的总和。通常超过1个月，您必须拥有一个非常好的源代码控制系统，良好的代码接口/架构或OCD开发人员或这三者的组合。

项目中大约25％的时间应该用于减少技术债务，其中大部分都包括重构代码。特征分支在重构期间是一个问题，因为预重构和重构后分支的合并可能非常困难。因此，您需要确保在开始重构之前合并所有功能分支。

Answer 4

持续集成的原始定义与构建服务器几乎没有关系，并且更加特定于“连续集成”多个工作流的实践。

该术语最初由Kent Beck在极限编程中创造或至少成为主流。

http://www.extremeprogramming.org/rules/integrateoften.html

背后的前提是;

• 提高了对其他人工作的可见度以及它可能如何重叠/影响您的工作。
• 降低可能导致意外破损的“大爆炸”合并的风险（通常在胁迫下）。
• 改进了“生产准备”，因为即使某些功能不完整，它也应始终可释放。

Git让它更容易，但对于XP的强大支持者，他们仍然会避免使用功能分支。相反，焦点将是通过抽象和特征切换在代码中进行分支。