git - 功能分支仍然(或曾经)被认为是一种不好的做法吗？

Question

来自 TFS 世界并且刚刚熟悉 Git，我将向我的团队提议我们应该 merge Gitflow workflow正如 famous article by Vincent Dressen 指出的那样前进。

几乎所有关于分支策略的现代文献都表达了 Gitflow 工作流的有效性，它是功能分支的扩展版本，但是来自有影响力的工程师的过时文章，例如 Martin Fowler's Feature Branch article (2009) , 反对一般的特征分支，支持持续集成。

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

然后福勒在 2011 年做出回应 by saying DVCS systems may make merging easier, but they still don't solve semantic conflicts .现在在 2014 年，我们有了语言感知 merge 工具，例如 Semantic Merge ，这可能会完全解决这个问题。

我的问题是

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

2. Fowler 的文章与现代开发有多大关系，尤其是与我们可以使用 SourceTree、Git、Jenkins 和其他代码审查软件等工具使功能分支等更容易的相关性？

Answer 1

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