如何重新設置為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是嗎？