如何重新设置为master而不是git pull origin master？

Question

我有一个旧的分支foo ，想成为最新的master 。

如果我执行$ git rebase origin master在foo分支，somewhy中所做的更改foo分支消失， foo得正好相同HEAD的master 。

为什么会这样？ 以及如何将我的foo分支重新设置为主节点？

这是我的git reflog 。 foo等于komoto/crop_image 。

fd8d9c1d (HEAD -> komoto/crop_image, origin/master, origin/HEAD, master) HEAD@{0}: rebase finished: returning to refs/heads/komoto/crop_image
fd8d9c1d (HEAD -> komoto/crop_image, origin/master, origin/HEAD, master) HEAD@{1}: rebase: checkout master
92284980 (tag: beta-test, origin/komoto/crop_image) HEAD@{2}: checkout: moving from master to komoto/crop_image

Answer 1

当心： git rebase origin master 意味着 git checkout master; git rebase origin 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遵循gitrevisions文档中概述的六步过程。 步骤6读取：

6. 否则， 引用/远程/ <refname> / HEAD（如果存在）。

因此，如果git rev-parse origin/HEAD成功（并且前面的五个步骤失败），则命令序列：

git checkout master
git rebase origin

等效于序列：

git checkout master
git rebase origin/master

如果您的master上没有从origin/master不能到达的提交，则不会执行任何操作。 有关可及性的良好介绍，请参见像（a）Git一样思考 。

你应该跑什么

我有一个旧的分支foo ，想成为最新的master 。

通常，我更喜欢这样做：

git checkout foo
git rebase master

但您可以-运行我认为人们应该避免的捷径（在旧版本的Git中它具有错误的失败模式）-运行：

git rebase master foo

请记住，rebase是通过复制提交来工作的，因此，这将首先枚举foo可以访问的所有非合并提交，这些非合并提交不能按拓扑排序的顺序从master进行访问， ¹将其哈希ID保存在某个地方。 ²然后它将使用git cherry-pick ³的等效项来复制每个此类提交，并且副本将在先前复制的提交之后着陆。 最先提交的提交在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'是与原始提交GHI对应的，精选的（即复制的）提交序列。

---

¹对于没有分支和合并的简单提交链，唯一正确的拓扑排序是： 从第一个到最后一个 。 如果您要重新提交的提交链中存在分支和合并序列，则重新进行基础处理会选择一些有效的拓扑排序，在流程中线性化提交并忽略合并提交。 实际上，有时候这是一个好主意，也是您想要的，但更多时候却不是。 Git正在开发一种新型的基础，它将能够更好地处理这一问题。 目前，有一个名为--preserve-merges的选项可以尝试完成此任务，但它确实不够用，除非在紧急情况下应避免使用。

²这是什么地方字面上文件充满了pick指令 ，当你使用git rebase -i 。 每个pick hash指令都告诉Git对那个特定的提交进行一次选择，列出其真实名称：其哈希ID。 对于某些其他类型的基准，这些ID不太容易看到-但它们仍保存在某个地方，能够在复制步骤失败时停止复制过程，然后在您手动修复问题后从停止的位置恢复起来。

³交互式rebase或使用-m或-s标志运行的rebase实际上使用git cherry-pick 。 所有rebase可能应该默认为该值，但是当前， 不使用-m或-s 非 git am --3way使用的是较旧的方法，该方法将git format-patch与git am --3way相结合。 另请参见git cherry-pick和git format-patch |有什么区别？ git是吗？