我有一个master分支,然后分支到我的feature分支:
A -> B -> C (master)
| -> D -> E (feature)
如果在master上有工作,我想将feature分支的基重定到新的master上,如下所示:
git checkout master
git pull
git checkout feature
git rebase master
result:
A -> B -> C -> F -> G (master)
| -> D -> E (feature)
现在,我想对特性进行一些交互式的重基化(例如,fixup):
git rebase -i HEAD~3
...
pick efgh456 message for commit D
f abcd123 message for commit E
save and quit
预期结果:
A -> B -> C -> F -> G (master)
| -> DE (feature)
实际结果:
A -> B -> C -> F -> G (master)
| -> DE (feature)
这里的git解释是什么?
3条答案
按热度按时间ruarlubt1#
正如其他答复和评论中所说:您只提供了部分信息,不足以确定您的问题。
这里有一个盲目的猜测:
如果你在混合中有 merge commits,你可能会遇到一些奇怪的事情,可能符合你所描述的:
git log
仍然会显示线性提交序列,这可能会让你相信你的 history 是线性的,HEAD~3
(或~n
)将指向比您认为的更晚的提交,git rebase
的默认行为是从它重写的序列中完全删除合并提交所以你可能会得到一个从比你预期的更早的提交开始的重定基准的历史。
一种可能性符合您的示例描述:
如果重定基后的历史记录实际上是:
然后
HEAD~3
实际上是C
(不是F
),git rebase -i HEAD~3
将请求重放F D E
的指令(G
将被丢弃),C
之上的线性历史。一个建议:
当您想使用
git log
查看自己的历史记录时(与之相反:在脚本中使用git log
的输出),always 添加--graph
选项。这将允许您在历史记录中实际查看fork和merge。查看我的回购历史记录的常用命令是:
另一个建议:
计算你的提交数(在正确的历史图上),或者使用分支名称而不是
HEAD~n
。以你在问题中描述的例子为例:将
D
和E
合并在一起只需要git rebase -i HEAD~2
或git rebase -i master
,这将在G
之上创建一个提交。zpjtge222#
您从未向我们展示您在启动交互式rebase后所采取的步骤,但如果您只想压缩前2个最近提交,您只需要:
这应该会带来一个编辑器,看起来像下面这样:
编辑此文件并更改为:
然后关闭/保存编辑器,这将启动变基。解决可能发生的任何合并冲突。现在你的历史应该看起来像:
oknrviil3#
另一种替代蒂姆的方法可能只是合并和挤压…我通常是这样做的:
如果它是一个短分支,我可能会重定基…如果它是一个更长的分支,我会走这条路。