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

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

4年前关闭。




Improve this question




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

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

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

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

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

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

两个开发人员将如何在同一功能上进行协作？在里面
基于特征的模型，两者都适用于特征分支。在里面
基于主干的模型，所有开发人员将在“所有的
功能”(不知何故)。对吗？

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

总体来说，相比于基于trunk的承载能带来哪些好处
基于特征的工作流程？

谢谢 :-)

Answer 1

您的引用 1已经讨论了有关代码审查的一些 Gist 。这个答案主要基于我在 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)?

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

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

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?

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

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

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?

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

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

我看到的最大好处是:

更线性的历史，更容易理解，更容易挑选和恢复。

较小的冲突解决方案，主要是在重大重构的情况下。

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