2016-06-28 79 views
2

我想弄清git-rebase的工作機制。 Documentation提供有關git-rebase的功能的信息,但不對它的操作方式發表評論?git rebase實現細節

我特地到source code,摸索出一些測試用例到目前爲止明白以下幾點:
1.混帳保持底墊的狀態.git/rebase-apply(與像補丁文件,最後提交,頭名等)
2. Git使用git-format-patch創造一切必要的補丁文件(這是內底墊申請)
3. Git使用git-am一個

應用這些補丁一個我覺得我缺少了很多的細節。我在哪裏可以找到實施細節?它是簡單地傾銷這個補丁並且天真地應用它嗎?

+0

請參閱[本](http://stackoverflow.com/a/11566503/2949612)回答。 – pRaNaY

+0

@pRaNaY,這個答案更多的是git rebase的功能。我在尋找它是如何做到的? –

+0

爲什麼不深入代碼本身? :) – everton

回答

3

你的總結基本完成。實際上,相對簡單。

  1. 首先,計算待完成的工作。這基本上是git rev-list <upstream>..<branch>來標識需要移動的所有提交。
    1. 如果您正在執行正常(基於補丁)的rebase,那麼每個提交的補丁都會生成並保存在rebase狀態文件夾(.git/rebase-apply)中。
    2. 如果您使用git rebase --merge調用了rebase,則提交將存儲在不同的狀態文件夾(.git/rebase-merge)中。
  2. 接下來,HEAD被分離並設置爲onto提交(新基地分支,在這裏您將應用這些更改)。
  3. 應用程序發生,直到提交不能應用。
    1. 如果您正在執行基於修補程序的rebase,則會按順序應用修補程序。如果修補程序未能應用,那麼Git將嘗試改爲提交有問題的cherry-pick。這是因爲cherry-pick能夠將合併衝突寫入索引和工作目錄。
    2. 如果你正在做一個基於合併的rebase,那麼提交是cherry-pick ed。
  4. 如果cherry-pick失敗,衝突,重訂停止,您(用戶)必須解決任何衝突和git add他們的索引。當您解決所有衝突時,您可以git rebase --continue
  5. 一旦應用了所有衝突,原始分支將更新爲指向最終的重新提交的提交。