通过合并进行拉动与通过基础进行拉动(保留合并)-可能存在差异吗?

时间:2018-10-08 19:13:02

标签: git merge rebase merge-conflict-resolution

我在git方面非常有经验,并且对git的概念非常熟悉,但是对于一个看似简单的问题(与合并和重新定标之间的差异有关),我找不到确切的答案。考虑我们有以下历史记录:

            D     E (origin/master)
            *-----*
A    B    C/    M (master)
*----*----*-----*
 \             /
  *-----*-----*
  X     Y     Z (dev)

它就是这样发展的:

  • master位于A上时,我们创建了一个功能分支dev
  • 已在X上提交了YZdev
  • 拉回购协议,master位于C
  • dev合并到master,创建M
  • 同时,在D上进行了Emaster的提交

因此,我们需要再次拉动才能推入master。我想考虑两个选择:

  1. 拉合并,即git pull rebase=false
  2. 具有保留基准的合并,即git pull rebase=preserve

我想了解这些命令是否可能会出现在不同的工作树中,或者一个命令是否会导致冲突,而其他命令则不会。

请记住,这是一种简化的情况。实际上,AE之间以及XZ之间的历史可能确实很长而且很复杂。但是,我们假设以下情况是正确的: AEZ 的合并基础。

在没有此限制的情况下,我可以轻松地回答,pull-merge和pull-rebase之间可能存在差异。例如。如果E恰好是一个合并提交,而Z是第二个父级,则将M合并到origin/master将是一个禁忌。但是,在origin/master上重新设置它很可能会导致冲突。

但是,如果我们确定之前没有devmaster的合并,是否有可能,例如第一个命令成功,而第二个命令导致冲突?

我尝试使用不同模式的文件编辑和重命名。但是,我没有找到一个例子。但是我无法证明这是不可能的。

1 个答案:

答案 0 :(得分:1)

我不确定rebase -p(或rebase -r)可以信任多远。但是我确实知道一种更简单的方法来摆脱您的情况。

使您的历史记录保持简单,而不必依赖复杂的合并和调整基准。您可以通过取消将dev合并到master,更新master,然后将dev合并到master中来实现。

          D - E [origin/master]
         /
A - B - C - M [master]
 \         /
  X - Y - Z [dev]

撤消合并。

git branch -f master C

          D - E [origin/master]
         /
A - B - C [master]
 \         
  X - Y - Z [dev]

更新母版。

git checkout master
git pull --rebase

                  [master]
A - B - C - D - E [origin/master]
 \         
  X - Y - Z [dev]

重做合并。

git merge dev

                [origin/master]
A - B - C - D - E - F [master]
 \                 /
  X - Y --------- Z [dev]

更好的是,将开发基于remaster,进行测试,然后合并。

在撤消合并并更新主服务器之后开始...

                  [master]
A - B - C - D - E [origin/master]
 \         
  X - Y - Z [dev]

将开发人员重新建立在主人员之上。

                  [master]
A - B - C - D - E [origin/master]
                 \         
                  X1 - Y1 - Z1 [dev]

测试开发者。

然后与--no-ff合并以保留历史上的“功能泡沫”。请注意,此合并不会进行任何更改。在测试dev时,您还测试了此合并。

                [origin/master]
A - B - C - D - E ------------ F [master]
                 \            /
                  X1 - Y1 - Z1 [dev]

优点是您可以以最终完整的形式测试dev,而不必合并。它使历史记录非常简单,没有不必要的更新合并。并且保留了代码考古学的分支。