我在git方面非常有经验,并且对git的概念非常熟悉,但是对于一个看似简单的问题(与合并和重新定标之间的差异有关),我找不到确切的答案。考虑我们有以下历史记录:
D E (origin/master)
*-----*
A B C/ M (master)
*----*----*-----*
\ /
*-----*-----*
X Y Z (dev)
它就是这样发展的:
master
位于A
上时,我们创建了一个功能分支dev
X
上提交了Y
,Z
和dev
master
位于C
dev
合并到master
,创建M
D
上进行了E
和master
的提交因此,我们需要再次拉动才能推入master
。我想考虑两个选择:
git pull rebase=false
git pull rebase=preserve
我想了解这些命令是否可能会出现在不同的工作树中,或者一个命令是否会导致冲突,而其他命令则不会。
请记住,这是一种简化的情况。实际上,A
和E
之间以及X
和Z
之间的历史可能确实很长而且很复杂。但是,我们假设以下情况是正确的: A
是E
和Z
的合并基础。
在没有此限制的情况下,我可以轻松地回答,pull-merge和pull-rebase之间可能存在差异。例如。如果E
恰好是一个合并提交,而Z
是第二个父级,则将M
合并到origin/master
将是一个禁忌。但是,在origin/master
上重新设置它很可能会导致冲突。
但是,如果我们确定之前没有dev
到master
的合并,是否有可能,例如第一个命令成功,而第二个命令导致冲突?
我尝试使用不同模式的文件编辑和重命名。但是,我没有找到一个例子。但是我无法证明这是不可能的。
答案 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
,而不必合并。它使历史记录非常简单,没有不必要的更新合并。并且保留了代码考古学的分支。