壓縮和刪除git中的提交有什么區別？

Question

假如我做

git rebase -i HEAD~3

並在文本編輯器中打開以下內容：

pick ae27841 Commit 1 
pick fd8a71e Commit 2
pick badd490 Commit 3

我想將這3次提交轉換為1次提交，以便可以將該提交推送到我的存儲庫中，然后調用請求請求。 我了解有兩種方法可以解決此問題：

1. 我可以留下一個承諾為pick和壁球其他兩個。 即

    pick ae27841 Commit 1 s fd8a71e Commit 2 s badd490 Commit 3 

2. 我可以刪除這3個提交中的2個。 即

    pick ae27841 Commit 1 

這兩個命令有什么區別？ 據我了解，每次提交都是項目的不同版本。 因此，我的最新提交將是我的最新版本，對嗎？ 因此，我最近要做的就是保留所有內容。 由於其他2個提交是項目的“較舊”版本，因此我不需要它們，因此可以刪除它們。 那么方法2是將我的3個提交轉換成一個的正確方法嗎？ 如果是這樣，我將需要壓縮哪種類型的提交呢？

這里正確的方法是什么？ 壓縮或刪除提交？

Answer 1

刪除提交時，您將從歷史記錄中刪除它引入的所有更改，即從其后的所有提交中刪除。 壓榨也從歷史記錄中刪除了提交，但其更改已合並到結果提交中。

Answer 2

更新 -從評論看來，誤解與問題有點不同，因此我在底部添加了一些注釋

---

原始答案

壓縮提交就是將其更改添加到之前的提交中。 刪除提交就是不執行更改。

所以如果你有

A --- B --- C <--(master)

如果您C.txt提交，則A創建A.txt ， B創建B.txt ， C創建C.txt 。

ABC <--(master)

其中ABC是創建A.txt ， B.txt和C.txt的單個提交，而如果刪除B和C得到

A <--(master)

並且僅創建A.txt 。

---

增加了筆記

因此，git COMMIT對象除其他外具有對當時表示您的項目內容的TREE對象的引用。 TREE大致是一個目錄列表，其中包含其他TREE對象（子目錄）和BLOB對象（文件）的名稱列表。

在內部（如果打包了對象）， BLOB可能表示為另一個BLOB的增量-但當前的修訂版通常是完整的對象，增量用於構造文件的較早版本。

無論哪種情況，在任何有效的倉庫中，您都可以從COMMIT上的TREE引用中重建項目的完整狀態。 PARENT用於歷史記錄跟蹤，但對於項目狀態的構造則不需要。

但是 ，當您在重建基准期間pick一個提交時，這並不意味着您正在復制該提交的TREE ； 而這意味着，git會找出差異犯下的之間TREE和提交的PARENT的TREE ，並應用一系列的變化。

在REBASE和MERGE操作中，根據提交與父提交的區別來處理提交的想法很重要。 從某種意義上說，即使提交是經過結構化的，因此它可以再現項目的快照，但通常認為將其表示為一組更改通常很有用。

Answer 3

壓縮和刪除在Git中在技術上是相同的。 他們創建新的提交，將一些現有的提交作為父提交，並且不會刪除任何提交。

假設提交歷史記錄為ABCD。 壓縮BCD時，將創建一個新的提交E作為A的新子級。新的提交包括BCD的更改。 BCD仍然在那里。 然后，當前ref（例如分支或HEAD）從A移到E（南瓜合並），或從D移到E（交互式變基）。 如果裁判在D時現在在E處，則似乎BCD丟失了，但實際上它們仍然存在。

至於通過選擇C到A的“刪除”，將創建一個新的提交C'作為A的新子代。C'具有等效的C更改（並不總是與C完全相同）。 BCD仍然在那里。 當前參考將A移至C'。 當您運行git reset ，當前ref從一個提交移動到另一個提交。

另一個示例是git commit --amend 。 當您為ABCD運行它時，新的提交D'被創建為C的新子代。 參考從D移到D'。 現在D似乎已刪除，但它仍然存在。 據說Amend修改和更新了最后的提交，但實際上它創建了一個新的同級提交。

Answer 4

首先，關於git的概念在這里是錯誤的：

據我了解，每次提交都是項目的不同版本。 因此，我的最新提交將是我的最新版本，對嗎？

當您刪除提交2和提交3時，提交1將更改。 讓我稱它為（提交1）”。 即使（Commit 1）'與Commit 1保持相同的提交消息，與以前的版本相比仍保持相同的修改，但它們不是同一版本。 （提交1）和提交1具有不同的版本哈希。

方法1 ：這就是您想要的。 保留代碼的最新版本，保留最后的提交消息。 但是您應該注意，HASH已更改。

方法2 ：不是您想要的。 在提交2和提交3中提交的代碼將丟失。