我非常喜欢Git中基于功能的工作流的想法：使用功能分支来支持并行开发。
在基于功能的工作流程中，我会在一个功能分支（off master）中开发我的任务，并且我会经常从master重新设置以避免潜在的冲突。如果是协作，我会将功能分支推/拉到遥控器。当准备好集成到master时，我打开一个从我的功能分支到master的pull-request，这样pull-requests会被peer监视并自动评估是否知道pull-request（我的功能分支合并为master）通过构建和单元测试。如果pull-request为“green”，那么我的功能分支将自动合并到master。
我发现上述工作流程很好。然而，在一些互联网帖子中，他们提倡“基于干线的开发”（例如1，2）。
就我而言，基于主干的开发不鼓励开发成单独的功能分支，但所有开发人员都发展成为主。这个模型鼓励开发人员每天（Martin Fowler的CI实践）整合到主人以避免冲突（相反，我要做的是在主人身上重新设置我的功能分支）。
我想知道这个模型对基于特征的模型有哪些优势。我对基于主干的模型有几个疑问：
谢谢 ：-）
您的参考1已经讨论了有关代码审查的一些观点。这个答案主要基于我在使用Gerrit工具和基于主干的工作流程方面的经验。
- 如何进行代码审查？在基于特征的模型中很容易：进入特征分支。在基于主干的模型中，由于所有提交都是在master中发布的，我如何才能对它们进行审核？事实上，如果我在合并到master中时解决冲突，那么这个提交是否会被审查（我不喜欢这样）？
理想情况下，基于主干的工作流中的代码审查应该在提交集成到master之前完成。手动，开发人员会将他们的提交推送到一些临时功能分支，并在批准后，将这些提交重新绑定到master并推送它们（可选地将它们压缩到单个提交中）。
Gerrit使这个过程自动化。当向Gerrit推送提交时，它会创建一个（几乎不可见的）临时分支集来保持正在审核的提交。在审核期间，所做的任何更正都会修改为正在审核的提交内容并再次推送给Gerrit。一旦获得批准，提交就会以原子方式集成到master中（用户可以选择如rebase，cherry-pick和merge之类的选项）。
Gerrit最适合用于基于主干的工作流中的代码审查，因为它促进了审核提交提交，并且推送的提交仅在通过审核后出现在主服务器中（更正是作为修改完成的，因此“错误”提交永远不会成为主服务器）。
- 两位开发人员将如何在同一功能上进行协作？在基于特征的模型中，两者都可以在特征分支上工作。在基于主干的模型中，所有开发人员都将在“所有功能”中进行协作（不知何故）。对？
对。由于所有功能都是在同一分支中开发的，因此所有开发人员都在同一分支上进行提交。代码审查（以及持续集成）将使该分支始终足够稳定（至少对于开发，如果不是用于生产）。
缺点是不同复杂功能的提交在日志中交错 - 添加一些问题跟踪系统的数量有很大帮助。但是，在代码审查之后压缩提交，或者使用Gerrit（强制reivew commit-by-commit，而不是逐个分支），经验表明大多数功能只是一次提交（相当于一个提交中的合并提交）基于特征的工作流程）。
- 我相信，基于主干的模型是“创造”的，以避免长期特征分支的问题是它们在将其合并到主线时的潜在冲突地狱。但是，如果功能分支是短暂的，并且如果它们经常从主线重新定位，那么问题是什么呢？
问题在于将一些长寿命的功能分支集成到主服务器中。然后，每个其他长期存在的功能分支都必须同时集成该完成功能的所有更改。如果已完成和重新定义的功能分支都进行了一些重构，那就更糟了。
- 总体而言，与基于功能的工作流程相比，哪些优势可以带来基于主干的优势？
我见过的最大好处是：
但是，我建议再次使用Gerrit（或类似的工具）在基于主干的工作流程中自动执行代码审查过程，而不是使用专为审查拉取请求（基于功能的工作流程）而设计的工具。
像你一样，Debitoor的开发人员对基于干线的开发有一些疑问。为了克服这些问题，他们想出了一种他们称之为Koritsu的创新解决方案。
Kōritsu是日语中的效率词，该方法旨在确保开发人员不会中断或阻止彼此。 Koritsu与短期功能分支非常相似，只不过它允许功能分支存活长达一周并自动将每个合并部署到主干。
Debitoor多年来一直在使用Koritsu进行网站和移动开发。对我们来说，它一直运行顺利，没有任何问题。有一点是肯定的：我们不会回到基于主干的开发
我们的首席技术官Allan撰写了一篇关于the problems with Trunk Based Development的文章，以及Koristu如何设计修复它们。这篇文章还包括他为基于主干的开发创新解决方案的演讲视频，该解决方案更详细地解释了所有内容。