我的理解是，出于所有意圖和目的，Git 提交是快照，而不是 diffs。因此，即使 Git 會在內部對快照進行“增量壓縮”以消除冗余，但理論上每次提交都是代碼庫在任何時間點的完整表示，并且不需要之前的提交即可。（我知道此時我可能會弄錯，但這是我目前的理解。）
所以如果是這樣的話，假設我有五個提交：
A - B - C - D - E
我決定不再關心 B 到 D - E 是我的規范提交。
在這種情況下，我想我會使用然后git rebase -i HEAD~4提交B、C 和 D。dropsquash
但是如果提交是快照，我為什么需要這樣做呢？在我看來，這意味著提交 E 取決于 B、C 和 D 中包含的歷史記錄，并且如果 Git 天真并允許我只是“洗掉”BC 和 D，那么一切都會崩潰。這暗示了差異系統，而不是快照系統。為什么 Git 不讓我直接洗掉這些提交而不抱怨，而不是要求我將它們“重新定位”到 A 上？難道一個完全基于快照的系統不允許我使用 E 作為“規范”提交，而不關心它之前的內容嗎？
如果我在這里的錯誤理解有任何更正，我將不勝感激。
uj5u.com熱心網友回復：
tl;dr：是的，在 git 中更改歷史意味著重寫提交，因為提交總是包含指向其前身的鏈接。
但是如果提交是快照，我為什么需要這樣做呢？在我看來，這意味著提交 E 取決于 B、C 和 D 中包含的歷史記錄，并且如果 Git 天真并允許我只是“洗掉”BC 和 D，那么一切都會崩潰。
是的，確切地說 -提交 E 確實取決于歷史。
然而，這并不是因為 Git 使用了差異，而是因為每個提交都包含一個指向其前身（又名“父級”）的鏈接。
這是 Git 中的一個核心設計決策——提交通過“反向鏈接”鏈接到歷史記錄中——每個提交都指向其前身（或合并提交的多個前身）。同樣至關重要的是，這個“指向”是指提交 ID，它是提交的散列 - 所以你不能只是“從歷史中洗掉提交” - 這樣做意味著更改某些提交的父級，這反過來需要重寫該提交，因為更改會更改提交。
這是由 Linus Torvalds 有意完成的，以確保特定的提交 ID 始終參考相同的代碼和相同的歷史記錄——這對于許多人會提供提交的 Linux 內核來說很重要。
uj5u.com熱心網友回復：
你的問題的存在理由：你有
A - B - C - D - E
但是你想要
A - E
美好的。讓我們首先澄清您問題中的一些誤解。
提交是不可變的
提交不僅僅是快照。它們也是不可變的。以任何方式與 E 不同的提交都不會是 E。它可能具有與 E 相同的提交訊息，但如果它與 E 完全不同，則它是不同的提交。
親子關系是提交的一部分
好吧，我剛剛說了，但我會再說一遍。提交不僅僅是它們的內容。它們包含一堆其他的東西，特別是包括關于他們的父母是誰的資訊。
好的。現在，在您的圖中，D 是 E 的父級。沒有 D 作為其父級的提交將具有不同的父級。我們剛剛說過提交是不可變的。因此，如果我們想象 E 以 A 作為其父級，那將不是 E。同樣，我們可以用一種非正式的方式稱它為“E”；它可能具有與 E 相同的提交訊息；但這將是一個不同的提交。
無需剪切和粘貼
以上足以解釋為什么你不能僅僅“剪切”B、C和D，然后“粘貼”E去追求A。你不能在任何地方“粘貼”E！只有一個 E——不僅在你的 repo 中，而且在整個宇宙中——而 D 是它的父代，這就是它的結束。
因此，為了從可見的歷史記錄中消除 B、C 和 D，我們必須以某種方式重寫E 以進行不同的提交，即以 A 作為其父級的提交。這就是為什么需要重新設定（或類似的東西）才能生成您想要的歷史記錄的基本原因。歷史
A - E
是不可能的。你可以擁有的是
A - E'
第二次提交，其名稱為“e-prime”，在你的腦海中與 E 有一些相似之處，但不是E。你需要一種連貫的方式來實作它。這就是為什么你必須跳某種舞蹈來改變歷史。
但這種舞蹈不需要變基——正如我們現在將看到的那樣。喝一杯咖啡，讓我們繼續吧。
無需變基
現在假設您的問題的意思是：B、C 和 D 是通往黃金真理的步驟，但 E 包含黃金真理，我真的不需要向我的人“展示我的作業”同事和世界。所以我想隱藏中間步驟，只是從 A 到 E——對不起，到 E'——作為對所發生事情的純粹而簡單的陳述。
然后你實際上不需要變基。說啊
git reset --soft <SHA of A>
git commit -m 'message identical to the E message'
這將導致您想要的
A - E'
我們剛剛做了什么？我們從您自己陳述的事實開始：提交包含快照。當我們說 時reset --soft，我們基本上將該快照的內容生成到作業樹和索引中。因此，當我們進行新的提交時，該提交是專案的快照，與 E 所描述的狀態完全相同。但是在我們進行這個新提交的時候，HEAD 是 A。所以這個新提交的父級是 A！問題解決了。
所以，是的，我們可以重新定位并壓縮中間提交以獲得相同的結果。但這只是對于那些不知道如何或不能被打擾的人更直接地完成同樣事情的一種便捷方式。Git 互動式變基是某些常見的歷史轉換型別的智能且方便的簡寫；但它沒有做任何你自己做不到的事情，以其他方式。
永遠不需要變基
我只是想告訴你，你永遠不需要變基。它所做的一切都可以通過一系列有時乏味和復雜的步驟來完成，這些步驟更加基本和直接并且（可能）不方便。
例如，假設您想消除 B 和 C，但保留 D 和 E（嗯，實際上是 D' 和 E'，正如我們已經知道的那樣 - D 將被 D' 替換，因為新提交的父級是 A，而不是 C，并且E 將被 E' 替換，因為新提交的父級是 D'，而不是 D)。
你可以在沒有互動式變基的情況下做到這一點。在 D 處啟動一個新分支。將該分支軟重置回 A 并使用 D 的提交訊息進行提交，就像我們之前所做的那樣。現在櫻桃選擇 E 到這個新分支的末尾，并給出結果提交 E 的舊訊息。現在清理分支情況，你就完成了。
我并不是說這比互動式變基更容易。顯然不是。但這不是重點。關鍵是互動式變基只是一個拐杖。一個非常棒的拐杖！但這不是魔術。
Drop不是壁球
最后，您在問題中說了一些非常錯誤的內容：您說的是“drop or squash”。這里沒有“或”：它們是完全不同的東西！Squashing 維護一系列 squash 中最后一次提交的內容。掉落不！如果您洗掉了 B、C 和 D，則生成的 E' 將包含一個與當前 E完全不同的快照！
例如，假設 B 包含A 沒有的新檔案myfile 。假設 C 和 D 和 E 也都有那個檔案。然后洗掉 B 會導致 E'缺少檔案myfile。
這是因為，雖然提交不是差異，但差異確實存在（在 Git 的頭腦中，沒有寫入歷史）并且它們在合并程序中使用。變基實際上是一種合并形式（我現在不想談這個）。因此，通過洗掉 B，您正在反轉將您從 A 帶到 B 的差異。由于該差異的一部分是myfile的創建，因此反轉該差異是一種表示不創建myfile的方式。所以當 rebase 結束時myfile不會出現在 E' 中，即使它確實出現在 E 中。
什么要壓扁
最后但同樣重要的是：您問題中的這句話也是錯誤的：“squash提交 B、C 和 D”。不。要通過互動式 rebase 獲得您想要的結果，您將壓縮 C、D 和 E。換句話說，選擇串列最初看起來像這樣：
pick f343cc4 B
pick f750aa9 C
pick 0105b79 D
pick 46fe327 E
你會編輯它看起來像這樣：
pick f343cc4 B
squash f750aa9 C
squash 0105b79 D
squash 46fe327 E
然后，您將選擇 E 的提交訊息作為生成的新提交的提交訊息。
uj5u.com熱心網友回復：
嗯...使用 rebase 只是一種工具，可以讓你輕松地做你想要達到的目標A <- E，對嗎？
如果您想擁有A <- E 與 E 中的內容一樣的內容，git rebase -i A那么您將squash在修訂版 C 中設定為 E，B 保留為pick.
如果你drop在 B、C 和 D 上做了，你會得到A然后 git 將嘗試應用 E 從 D 引入的更改，所以你可能會遇到沖突......你可能不會，這取決于 A 是什么樣的，以及 D 和 E 看起來能夠分辨的內容。
回到我的觀點，你可以用命令做同樣的事情......第一個選項：
git checkout E
git reset --soft A
git commit -m "The new E"
或者你也可以運行：
git commit-tree -p A -m "The new E" E^{tree}
但是我們現在正在深入研究，因為這是一個管道命令，不應該由我們外行使用（盡管它仍然是可能的，正如你所看到的）。
第二種選擇是：
git checkout A
git cherry-pick E
因此，實際上不需要使用 rebase，它使用起來非常簡單。
它絕對是基于快照的......看看https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
uj5u.com熱心網友回復：
有關大多數答案，請參見馬特的答案。不過，作為一個稍微不同的“為什么git rebase首先存在”問題的答案，讓我們看看我所說的快照差異對偶性。
假設我們有一個“基本快照”和一個差異或補丁：
$ git checkout v1.0.7
$ patch -p1 < /tmp/patch-to-v1.0.7
如果這個補丁干凈地應用了——如果它是從 v1.0.7這個軟體生成的，我們可能會期望它——我們現在在我們的 Git 存盤庫中擁有補丁源，可以用作新的快照：
$ git switch -c patch-branch
$ git add .
$ git commit -m "temporary: save the patch I got from Fred"
管他呢。
同時，一旦我們制作了這個快照，我們就可以從快照轉換為補丁：
$ git format-patch --stdout patch-branch^ > /tmp/new-patch
并且新補丁應該在功能上與原始補丁相同，即使差異由于某種原因有些不同。
最終，給定任意兩個快照，我們可以形成一個補丁，并且給定任何正確的基礎和一個補丁，我們可以形成一個新的快照。這會產生一個簡單的補丁代數，其中 B P = S，或 P = S - B。
這個代數雖然有一些問題。給定一系列補丁 P 1 , P 2 , ..., P n，加上一個基數 B，我們可以制作任意數量的快照。但是一些 P i可以抵消或部分抵消一些 P j。因此，如果我們選擇在一組補丁中重新排序某些補丁，或者洗掉或增加任何補丁，我們必須非常小心。
此外，這一切都在合并時分崩離析，合并有多個父級。在某個基礎加上一個補丁或補丁系列之后的合并提交M，它是一個基礎加上兩個補丁系列加上一個最終的“組合”操作，一般來說，“組合”操作不能表示為一個簡單的補丁。即使兩個補丁系列都只包含一個補丁也是如此：只有當補丁系列中的一個完全為空時，才能保證合并操作為空。
該git rebase命令是 Git 對這種二元性的讓步，就 Git 而言。具體來說，每個要復制的提交都會轉換為一個補丁，以及一些額外的資訊。該額外資訊包含足夠的資料來識別要修補的每個檔案的特定基本版本。
Git 中最簡單的表達方式是git cherry-pick. （另一種方法是通過 獲得的git format-patch，它以不同的方式對必要的額外資訊進行編碼。）給定一個普通的（非合并，單父）提交，git cherry-pick將提交中的快照與其父級中的快照進行比較。結果是git show或git format-patch將顯示的補丁：它是將先前或父快照（或“原像”）拍攝到后續或子快照（或“后像”）所需的。
然后我們想將這個相同的增量應用到其他一些現有的快照，通常存盤在當前提交中。有時這很容易，但有時很難。事實證明，我們想要的額外資訊與我們在操作期間想要的完全相同git merge。也就是說，應用此增量的理想方法是使用同一父提交與當前提交的差異：這將告訴我們是否由于我們自己的設定差異而需要在某個檔案中上移或下移某些更改，或者甚至可能由于重命名操作或其他原因而移動到完全不同的檔案名。
因此，該git rebase命令從字面上使用git cherry-pick——或者更準確地說，在 2.13 之前的許多 Git 版本中，git rebase -i是一個運行git cherry-pick. 從那時起，Git 呼叫的序列器（它實作了cherry-pick 和 revert）已經被擴充以實作 rebase，所以現在它們都是一回事。在 Git 2.23 左右——Git 的發行說明使這有點模棱兩可——甚至非互動式 rebase 也被轉換為使用這種方法；舊版本有一個基于非互動式變基的后端git-format-patch。git-am舊的基于“am”的變基在git format-patch輸出中使用“index:”行來定位檔案的合并基本版本，而不是直接使用提交，這仍然發生在電子郵件補丁中。
不過，無論哪種方式，Git 都會在需要時使用對偶技巧將快照轉換為增量。合并操作使用增量以及一些共享的基本版本來“添加傳入的更改”到一些現有的更改集。這使用了我們的補丁代數，其內部取消的小問題，讓我們盡可能接近我們想要的。（有時補丁代數取消是有幫助的，有時它們是有害的，所以總的來說它是一種洗滌。）
最后git rebase，不管它的具體實作如何，都只是一個得到我們想要的東西的工具。我們必須決定我們想要什么以及這是否是一個好工具。有時已經有更好的工具了。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/505908.html