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