gitrebase省略了哪些提交？

git 檔案說明如下：

然后將之前保存到臨時區域的提交按順序一一重新應用到當前分支。請注意，HEAD中引入與HEAD..upstream中的提交相同的文本更改的任何提交都將被省略（即，將跳過已在上游接受的具有不同提交訊息或時間戳的補丁）。

這對我來說似乎有點令人困惑。這是否僅僅意味著在要復制的提交集中省略了正在被重新設定的分支中的任何提交，而這些提交不會改變被重新設定到的分支中的任何內容？

如果是這樣的話：

• 如果指定了 new_base 怎么辦？這是否會將提交集從 HEAD..upstream 更改為 HEAD..new_base ？
• 為什么使用范圍？為什么不直接說“HEAD 中引入與上游提交相同的文本更改的任何提交都被省略了”？

uj5u.com熱心網友回復：

這是否僅僅意味著在要復制的提交集中省略了正在被重新設定的分支中的任何提交，而這些提交不會改變被重新設定到的分支中的任何內容？

不。要深入淺出，你可以看看什么git rebase是候選人

git rev-list --reverse --no-merges @{upstream}..

以及它正在檢查的提交，以避免重新應用已經應用的提交，使用

git rev-list --reverse --no-merges ..@{upstream}

檢查使用git patch-id. 要查看 git 在看什么，

git rev-list --reverse --first-parent --no-merges @{upstream}.. \
| git diff-tree --patch --stdin \
| git patch-id

和

git rev-list --reverse --no-merges ..@{upstream} \
| git diff-tree --patch --stdin
| git patch-id

除了該序列位于rebase 真正運行以獲取其資訊--right-only的內部。git format-patch --right-only @{u}...

uj5u.com熱心網友回復：

除了jthill 的回答，它涉及到git rev-list使用--no-mergesand的一些技巧的細節git patch-id，我將添加以下注釋：

• --no-merges如果你使用--rebase-merges.
• 使用--fork-point（有時是默認設定），rebase 將忽略根據上游reflog中包含的upstream..HEAD資料列出的提交。

后者多年來經歷了多次變化。起初，fork-point 模式只在git pull腳本中實作。然后它被移動到git rebase正確的位置，并調整了實作，現在您可以運行git merge-base --fork-point以找到 fork-point 提交。

使用“fork point”是為了在處理上游 rebase時提供幫助。也就是說，假設您的 Git 存盤庫克隆位于origin. 您已將提交發送給控制該存盤庫的任何人。他們可能會也可能不會接受你的一些提交。他們可能會也可能不會接受其他用戶的其他提交。但是，在某些時候，他們也運行git rebase --interactive自己并從他們的提交集中洗掉了他們在某個時候擁有的一些提交，您在某個時候重新基于這些提交。

讓我們繪制一個示例情況。他們從這個開始：

...--o--o--*   <-- main

您克隆了存盤庫并創建了自己的三個提交，我們將E-F-G無緣無故地呼叫它們：

...--o--o--*   <-- main, origin/main
            \
             E--F--G   <-- feature-X

他們選擇了四個新的提交，還沒有一個匹配你的，所以當你運行時，git fetch你得到了：

             A--B--C--D   <-- origin/feature-X
            /
...--o--o--*   <-- origin/main
            \
             E--F--G   <-- feature-X

然后，您feature-X在他們的feature-X(your origin/feature-X) 上重新設定您的基礎以獲得：

                        E'-F'-G'  <-- feature-X
                       /
             A--B--C--D   <-- origin/feature-X
            /
...--o--o--*   <-- origin/main
            \
             E--F--G   [abandoned]

然后他們認為 commit不好C，所以他們重寫了他們的 drop并用新的 commit替換了他們。當你運行時，你會得到：feature-XCD'D'git fetch

                  C--D--E'-F'-G'  <-- feature-X
                 /
             A--B--D'  <-- origin/feature-X
            /
...--o--o--*   <-- origin/main
            \
             E--F--G   [abandoned]

然后他們決定他們喜歡您的提交G或G'（無論是哪個）如此多的，以至于他們將其合并到他們的 feature-X中，這樣如果您git fetch再次獲得：

                  C--D--E'-F'-G'  <-- feature-X
                 /
             A--B--D'-G"  <-- origin/feature-X
            /
...--o--o--*   <-- origin/main
            \
             E--F--G   [abandoned]

他們G"是他們的副本 your Gor G'：它引入了與您的 commit 對您的 commit所做的相同的更改，但行號不匹配。G'F'

理想情況下，您希望git rebase以某種方式自動確定他們的提交C和D，現在看起來它們是您的提交，是他們的提交并且被放棄以支持他們D'，并且他們的提交G"與您的G'. 所以你會想要git rebase產生這個：

                  C--D--E'-F'-G'  [abandoned]
                 /
             A--B--D'-G"  <-- origin/feature-X
            /          \
...--o--o--*            E"-F"  <-- feature-X
            \
             E--F--G   [abandoned]

也就是說，您希望您git rebase：

• 不要復制 commit C，即使你有一個而他們沒有；
• 不復制提交D'，并且
• 不復制提交G'。

使用的補丁 ID 技巧git rebase可能會在這里處理D'andG'但不會正確省略C. 分支點代碼將正確省略C，前提是您的origin/feature-X分支的 reflog 中包含正確的資訊。只要所有這些活動都發生在過去 90 天內左右，這通常是正確的。

有關該--fork-point選項的更多資訊，請參閱Git rebase-commit select in fork-point mode和（當然）檔案。git rebase

uj5u.com熱心網友回復：

這對我來說似乎有點令人困惑。這是否僅僅意味著在要復制的提交集中省略了正在被重新設定的分支中的任何提交，而這些提交不會改變被重新設定到的分支中的任何內容？

是的，主要是因為在正常情況下，除非明確告知，否則 Git 永遠不會記錄空提交。相反，您會在這里得到一條訊息“您的作業目錄是干凈的”，由git status.

如果指定了 new_base 怎么辦？這是否會將提交集從 HEAD..upstream 更改為 HEAD..new_base ？

我相信這確實是他們所說的“上游”。

為什么使用范圍？為什么不直接說“HEAD 中引入與上游提交相同的文本更改的任何提交都被省略了”？

因為這就是 Git 實際上區分兩個分支的方式。這個范圍的底部提交是你的兩個分支都開始分叉的地方。

標籤：混帐

上一篇：Git不會洗掉本地倉庫中已洗掉的檔案

下一篇：強制推送遠程后Git獲取筆記