我有一个旧的分支机构foo
,想将其分支到最新的master
。
如果我在$ git rebase origin master
分支上执行foo
,
为什么在foo
分支中所做的更改会消失,并且foo
与HEAD
的{{1}}一样。
为什么会这样?
以及如何将我的master
分支重新建立到主服务器上?
这是我的foo
。 git reflog
等于foo
。
komoto/crop_image
答案 0 :(得分:3)
当心:git rebase origin master
表示 git checkout master; git rebase origin
(然后返回原始分支)。这就是为什么您的reflog显示:
HEAD@{1}: rebase: checkout master
(然后是HEAD@{0}: rebase finished: returning to refs/heads/komoto/crop_image
:显然,您刚开始时就在komoto/crop_image
上。)
当您在此位置参数中单独写origin
时,您的Git遵循the gitrevisions documentation中概述的六步过程。步骤6的内容为:
- 否则, refs / remotes /
/ HEAD (如果存在)。
因此,如果git rev-parse origin/HEAD
成功(并且前面的五个步骤失败),则命令序列:
git checkout master
git rebase origin
等效于序列:
git checkout master
git rebase origin/master
如果您的master
上没有从origin/master
无法访问的提交,则不会执行任何操作。有关可达性的良好介绍,请参见Think Like (a) Git。
我有一个旧的分支机构
foo
,想将其分支到最新的master
。
通常,我更喜欢这样做:
git checkout foo
git rebase master
但是您可以运行-
,因为我认为人们应该避免这种捷径(在旧版本的Git中它具有错误的失败模式)。git rebase master foo
请记住,通过复制提交可以进行重新设置,因此,在拓扑结构中,它首先将枚举foo
可以访问的所有非合并提交,而master
不能访问这些提交。排序的顺序, 1 将其哈希ID保存在某个地方。 2 然后它将使用与git cherry-pick
3 等效的副本来复制 每个此类提交,副本将在先前复制的提交之后着陆。首先复制的提交会在master
的尖端之后登陆:
...--A--B--C--...--N--O <-- master
\
G--H--I <-- foo
成为:
G'-H'-I' <-- foo
/
...--A--B--C--...--N--O <-- master
\
G--H--I [abandoned, but still findable as foo@{1}]
其中G'-H'-I'
是与原始提交G-H-I
相对应的,经过精心挑选(即复制)的提交的顺序。
1 对于没有分支和合并的简单提交链,唯一正确的拓扑排序是:从头到尾的顺序。如果您要重新提交的提交链中有分支和合并序列,请重新选择 some 有效的拓扑排序,在流程中线性化提交并忽略合并提交。实际上,有时候这是一个好主意,也是您想要的,但更多时候却不是。 Git正在开发一种新型的基础,它将能够更好地处理这一问题。当前,有一个名为--preserve-merges
的选项试图完成这项工作,但它实际上并不足够,除非在紧急情况下应该避免。
2 当您使用pick
时,此某处实际上是位于充满git rebase -i
指令的文件中。每个pick hash
指令都告诉Git对那个特定的提交进行一次精心挑选,列出其真实名称:其哈希ID。对于某些其他类型的基准库,这些ID不太容易看到-但它们仍保存在某个地方,能够在复制步骤失败后停止复制过程,然后恢复从手动修复问题后停止的地方开始。
3 一个交互式变基或使用-m
或-s
标志运行的变基实际上使用git cherry-pick
。所有rebase可能都应该默认为该值,但是当前不不使用 的 non 交互式rebase使用-m
或-s
使用结合了旧方法的旧方法git format-patch
与git am --3way
。另请参见What is the difference between git cherry-pick and git format-patch | git am?