Question

我的git信息库当前有两个从master分支创建的功能分支。我们将两个功能分支称为A和B。在创建B之前先创建4次提交。目前，A和B几乎没有重叠，只有一个小的合并冲突。

由于业务计划的原因，我不能再将A和B合并为主帐户45天。在继续工作时，我现在很难记住哪个分支包含哪些更改，并且我想将两个分支合并为一个。将A合并为B（旧的合并为新的）有什么优点和缺点？

git checkout B
git merge A

将B合并为A（将新的合并为旧的）有什么优点和缺点？

git checkout A
git merge B

Answer 1

从代码的角度来看，只要您在合并时做出相同的合并冲突解决决定，这两种方法都会产生相同的结果。

从阅读git历史记录的角度来看，将较旧的分支合并到较新的分支更有意义，因为您可以更轻松地跟踪提交日期，但这只是用户的喜好。

我建议，由于您的管理方式不佳，请将这两个分支合并为一个单独的临时第三分支。

git checkout A # can checkout B as well
git checkout -b temporary-C-branch
git merge B # or A if you checked out B first. Also think about using --no-ff if you want a merge commit as well

这样，合并时就不必弄乱A和B。

Answer 2

优缺点

没有。将A合并为B并将B合并为A只是两件事-两件事。他们之间没有选择。它们不是互斥的（你们既可以做，也可以经常被人们做），而且一个并不比另一个“好”。您要做的是做那件事，因为那是您想要做的。

拓扑差异仅在于各个分支发生什么，哪个是“第一父级”。

如果您在A上并且将B合并为A，则B在合并提交之前停止；合并提交在A上进行，您仍在A上，并且对A的上一次提交是合并提交的第一个父级（而B是其第二个父级）。
如果您在B上并且将A合并到B中，那么情况恰恰相反：A在合并提交之前停止；合并提交在B上进行，您仍在B上，并且B上的先前提交是合并提交的第一个父级（而A是其第二个父级）。

当然，谁是--ours和谁是--theirs之间也存在差异。如果您选择一些在冲突时使用该区别的合并策略，那将很重要。但是，在所有其他条件相同的情况下，无论执行哪种“合并”方式，合并提交的内容都是完全相同的。

将旧分支合并为新分支或将新分支合并为旧分支

2 个答案: