Git 多分支的合并顺序

我在计算合并分支的最佳顺序时遇到了一些困难，以避免合并冲突和更容易的代码审查。我将用下图来描述我的情况

如您所见，我从master创建了分支V，并添加了一些提交。然后我还有分支K，它是分支V的分支，也有一些提交。我希望有两个合并请求供人们查看，所以我最初的计划是将分支K设置为合并到分支V，然后将分支V合并到主分支

这是最好的策略吗？我不想将分支K设置为合并到master中，因为在代码审查中，分支K和master之间的差异包括分支V提交时产生的差异

---

我只是想知道最好的合并顺序是什么。谢谢

是的，从的角度来看，将一份请购单从

V

修改为

master

，将另一份请购单从

K

修改为

V

最有意义，因为每份请购单只会显示其相关的代码更改。我想说的是，让审稿人的生活更轻松应该是你的首要任务

一旦批准这些PRs进行合并，您可以：

首先合并

K

->

V

，然后合并

V

->

master

首先合并

K

->

master

，然后将另一个PR的基础更改为

master

，并将其合并

选择2。为了更好地工作，

K

本身需要有意义，因为您不应该在任何时候将分解的内容合并到

master

如果您选择选项1。我还建议在合并

K

后编辑

V

->

master

PR描述，以反映它现在包含更多（已批准的）更改

---

一般来说，我建议使用PR描述来描述两个PRs之间的关系，以便让审查人员了解完整情况

分支机构K拆分后，分支机构V是否有提交（图中未显示）？或者V真的如图所示变成了K吗？@matt K总是从分支V的前面分支。如果它落后了，我将重新设置分支K的基础，使其位于V的前面。在这种情况下，如图所示，没有有意义的分支V。只需将K合并到master中。明白了。在某些情况下，有人在Branch V上开发，我正在开发新功能，但需要Branch V的内容。我从第五分支分支分支出来做这件事。你认为有更好的选择吗？没有。只要你和“某人”保持密切联系，那就是正确的行为方式。前几天同样的事情发生在我身上；“有人”正在处理一个功能分支，他说，“帮我做这个，处理下面的子功能”。因此，我进行了分支，希望合并到feature分支中。没有公关；只是我们两个在一起工作。你也可以这么做，但没有意义；这将是一个快速前进的过程当我的朋友完成了所有的功能分支，然后是公关的时候了。