在 Git 中使用基于主干与基于功能的工作流的优缺点是什么？

What are the pros and cons of using a trunk-based Vs feature-based workflow in Git?

提问by letimome

I pretty much like the idea of the feature-based workflow in Git: using feature branches to support parallel development.

我非常喜欢 Git 中基于功能的工作流的想法：使用功能分支来支持并行开发。

In a feature-based workflow, I would develop my tasks in a feature branch (off master), and I would rebase often from master to avoid potential conflicts. If collaborative, I will push/pull the feature branch to the remote. When ready to integrate to master, I open a pull-request from my feature branch to master, so that the pull-requests is reviewed by peers & automatically assessed to know if the pull-request (the merge of my feature branch into master) passes the build and unit-tests. If the pull-request is "green" then my feature branch is automatically merged to master.

在基于功能的工作流中，我会在一个功能分支（非 master）中开发我的任务，并且我会经常从 master 重新定位以避免潜在的冲突。如果协作，我会将功能分支推/拉到远程。当准备好集成到 master 时，我打开一个从我的特性分支到 master 的 pull-request，这样 pull-request 就会被同行并自动评估以了解 pull-request（我的特性分支合并到 master）通过构建和单元测试。如果拉取请求是“绿色”，那么我的功能分支会自动合并到主分支。

I find the aforementioned workflow fine. However, in some internet posts, they advocate for a "trunk-based development" (e.g. 1, 2).

我发现上述工作流程很好。然而，在一些互联网帖子中，他们提倡“基于主干的开发”（例如 1、2）。

As far as I am concerned, trunk-based development does not encourage developing into separate feature branches but all developers develop into master. This model, encourages that developers integrate daily (Martin Fowler's CI practice) to the master to avoid conflicts (in contrast, what I would do is to rebase my feature branch on master).

就我而言，基于主干的开发不鼓励开发成单独的功能分支，而是所有开发人员都开发成 master。该模型鼓励开发人员每天将（Martin Fowler 的 CI 实践）集成到 master 以避免冲突（相反，我会做的是将我的功能分支重新建立在 master 上）。

I was wondering which advantages this model would carry over the feature-based model. I have several doubts with the trunk-based model:

我想知道这个模型将继承基于特征的模型的哪些优势。我对基于主干的模型有几个疑问：

1. How would code-review be done? In feature-based model is easy: into the feature branch. In the trunk-based model, since all the commits are published in master, how can I make them reviewed? In fact, if I resolve conflicts when merging into master, wouldn't this commits appear as to be reviewed (i wouldn't like that)?

2. How would two developers collaborate on the same feature? In the feature-based model, both would work on the feature branch. In the trunk-based model, all developers would be collaborating in "all the features" (somehow). Right?

3. I believe, the trunk based model was "created" to avoid the problem of long-lived feature branches are their potential conflict hell when merging it to the mainline. However, if feature branches are short-lived, and if they are often rebased from the mainline, what is the issue then?

4. Overall, which benefits can carry the trunk-based compared to the feature-based workflow?

1. 如何进行代码？在基于特征的模型中很容易：进入特征分支。在基于主干的模型中，由于所有提交都发布在 master 中，我该如何进行？事实上，如果我在合并到 master 时解决了冲突，这个提交会不会被（我不喜欢那样）？

2. 两个开发人员将如何在同一功能上进行协作？在基于特征的模型中，两者都适用于特征分支。在基于主干的模型中，所有开发人员都将在“所有功能”（以某种方式）方面进行协作。对？

3. 我相信，“创建”基于主干的模型是为了避免长期存在的功能分支在将其合并到主线时潜在的冲突地狱的问题。但是，如果功能分支是短暂的，并且如果它们经常从主线重新定位，那么有什么问题呢？

4. 总体而言，与基于特征的工作流相比，基于主干的工作流可以带来哪些好处？

Thanks :-)

谢谢 ：-）

采纳答案by André Sassi

Your reference 1already discuss some points about code-review. This answer is primarily based on my experience at work with the Gerrittool and trunk-based workflow.

您的参考文献1已经讨论了有关代码的一些要点。这个答案主要基于我使用Gerrit工具和基于主干的工作流的经验。

1. How would code-review be done? In feature-based model is easy: into the feature branch. In the trunk-based model, since all the commits are published in master, how can I make them reviewed? In fact, if I resolve conflicts when merging into master, wouldn't this commits appear as to be reviewed (i wouldn't like that)?

1. 如何进行代码？在基于特征的模型中很容易：进入特征分支。在基于主干的模型中，由于所有提交都发布在 master 中，我该如何进行？事实上，如果我在合并到 master 时解决了冲突，这个提交会不会被（我不喜欢那样）？

The code-review in trunk-based workflow ideally should be done before commits integrate into master. Manually, developers would push their commits to some temporary feature branch and, when approved, rebase those commits into master and push them (optionally squashing them into a single commit).

理想情况下，应该在提交集成到 master 之前完成基于主干的工作流中的代码。手动，开发人员会将他们的提交推送到某个临时功能分支，并在获得批准后，将这些提交重新设置为 master 并推送它们（可选地将它们压缩为单个提交）。

Gerrit automates this process. When pushing a commit to Gerrit, it creates an (almost invisible) temporary set of branches to hold the commit under review. During review, any corrections made are amended to the commit under review and pushed again to Gerrit. Once approved, the commits are integrated into master atomically (user can chose how among options like rebase, cherry-pick and merge).

Gerrit 使这个过程自动化。将提交推送到 Gerrit 时，它会创建一个（几乎不可见的）临时分支集来保存正在的提交。在期间，所做的任何更正都会修改为中的提交，并再次推送到 Gerrit。一旦获得批准，提交将自动集成到 master 中（用户可以在 rebase、cherry-pick 和 merge 等选项中选择如何）。

Gerrit is best used for code-review in trunk-based workflow, since it promotes review commit-by-commit and the pushed commits only appear in master after passing review (corrections are done as amends, so "wrong" commits never go to master).

Gerrit 最适合用于基于主干的工作流中的代码，因为它促进了逐个提交的，并且推送的提交仅在通过后出现在 master 中（更正作为修正完成，因此“错误”提交永远不会转到 master ）。

2. How would two developers collaborate on the same feature? In the feature-based model, both would work on the feature branch. In the trunk-based model, all developers would be collaborating in "all the features" (somehow). Right?

2. 两个开发人员将如何在同一功能上进行协作？在基于特征的模型中，两者都适用于特征分支。在基于主干的模型中，所有开发人员都将在“所有功能”（以某种方式）方面进行协作。对？

Right. Since all features are developed in the same branch, all developers commits on that same branch. Code review (and continuous integration) will give some confidence that this branch is always sufficiently stable (at least for development, if not for production).

对。由于所有功能都在同一个分支中开发，因此所有开发人员都在同一个分支上提交。代码（和持续集成）会让人相信这个分支总是足够稳定（至少对于开发来说，如果不是对于生产来说）。

The drawback is that commits of different complex features become interleaved in the log - adding numbers of some issue tracking system helps a lot. However, squashing commits after code-review, or using Gerrit (which forces the reivew commit-by-commit, not branch-by-branch), experience has shown that most features are just a single commit (equivalent to the merge commit in a feature-based workflow).

缺点是不同复杂功能的提交在日志中交错 - 添加一些问题跟踪系统的数量有很大帮助。然而，在代码后压缩提交，或使用 Gerrit（强制逐个提交，而不是逐个分支进行），经验表明大多数功能只是一个单一的提交（相当于一个合并提交）基于特征的工作流）。

3. I believe, the trunk based model was "created" to avoid the problem of long-lived feature branches are their potential conflict hell when merging it to the mainline. However, if feature branches are short-lived, and if they are often rebased from the mainline, what is the issue then?

3. 我相信，“创建”基于主干的模型是为了避免长期存在的功能分支在将其合并到主线时潜在的冲突地狱的问题。但是，如果功能分支是短暂的，并且如果它们经常从主线重新定位，那么有什么问题呢？

The problem lies when some long-lived feature branch is integrated into the master. Then every other long-lived feature branch will have to integrate all changes from that finished feature all at once. That's even worse if both the finished and the rebasing feature branches have done some refactoring.

问题在于当一些长期存在的功能分支被集成到 master 中时。然后每个其他长期存在的功能分支都必须一次集成来自该完成功能的所有更改。如果完成的和变基的功能分支都做了一些重构，那就更糟了。

4. Overall, which benefits can carry the trunk-based compared to the feature-based workflow?

4. 总体而言，与基于特征的工作流相比，基于主干的工作流可以带来哪些好处？

The greatest benefits I have seen are:

我看到的最大好处是：

• More linear history, which is easier to understand and to make cherry-picks and reverts.
• Smaller conflict resolutions, mainly in case of major refactorings.

• 更线性的历史，更容易理解，更容易挑选和恢复。
• 较小的冲突解决方案，主要是在重大重构的情况下。

However, I'd like to recommend again using Gerrit (or some similar tool) to automate code-review process in trunk-based workflow instead of using a tool designed for reviewing pull-requests (feature-based workflow).

但是，我想再次推荐使用 Gerrit（或一些类似的工具）在基于主干的工作流中自动化代码过程，而不是使用专为拉取请求（基于功能的工作流）而设计的工具。

回答by André Sassi

Like you, the developers here at Debitoor had some doubts with trunk based development. To overcome these problems, they came up with an innovative solution they call Koritsu.

像您一样，Debitoor 的开发人员对基于主干的开发也有一些疑问。为了克服这些问题，他们提出了一种称为 Koritsu 的创新解决方案。

Kōritsu is the Japanese word for efficiency, and the approach is designed to ensure developers never interrupt or block each other. Koritsu is fairly similar to short lived feature branches, except it lets the feature branches live for up to a week and automatically deploy every merge to trunk.

Kōritsu 在日语中是效率的意思，这种方法旨在确保开发人员不会互相干扰或阻止。Koritsu 与短期功能分支非常相似，除了它让功能分支最多存活一周并自动将每个合并部署到主干。

Debitoor has been using Koritsu for several years for our website and mobile development. For us, its been been running smoothly without any issues. One thing is for sure: we are not going back to Trunk Based Development

Debitoor 多年来一直使用 Koritsu 进行我们的网站和移动开发。对我们来说，它一直运行顺利，没有任何问题。有一件事是肯定的：我们不会回到基于主干的开发

Our CTO Allan has written an article about the problems with Trunk Based Developmentand how Koristu is designed to fix them. The article also includes a video of a talk he gave on his innovative solution to Trunk Based Development, which explains everything in more detail.

我们的 CTO Allan 写了一篇关于基于主干开发的问题以及 Koristu 如何解决这些问题的文章。这篇文章还包括一段他关于基于主干开发的创新解决方案的演讲视频，其中更详细地解释了所有内容。