我應該更喜歡git merge還是git merge --squash

Question

我一直在前後走，不能完全決定哪個工作流程更好。我應該更喜歡壓縮合併到主人的分支。或者我應該合併它們。

我贊成合併-squash並一直使用它。

優點爲合併--squash：

1. 清潔的歷史。
2. 更容易使用二分法。

有沒有什麼原因我不應該使用合併--squash並使用普通的舊合併來代替？

Answer 1

這取決於。

壓扁失去了信息，壓扁是否重要取決於信息是否重要。對於六個月或六年之後的人來說，重要的是要弄清爲什麼一行代碼就是這樣的。這取決於分支中的內容，更改的數量，更改的大小以及日誌消息的效果。

簡單的經驗法則？考慮壁球的結果並問自己：「如果我是在主人身上編碼，我會這麼做嗎？」如果答案是肯定的，差異和日誌合在一起將允許未來的人找出爲什麼一行代碼改變了，然後壓縮合並。

如果答案是否定的，這將不是一個可以接受的提交承諾，有太多的變化或太多交織在一起的變化，那麼不要擠壓它。合併它，也許在考慮分支內的任何提交是否可以被壓縮在一起。

至於擠壓是「更清潔」，「更容易對分」......我覺得這只是真實的表面。如果你拿出書架上所有書籍的頁面，並將它們縫製成一個「更乾淨」的巨大封面，那麼你現在只需要擔心一本書。如果他們是一羣獨立自主的小說，那麼它就沒有幫助。如果他們是年度會議報告，它們可能會更好地綁定在一起。

從一種意義上說，你不太可能有一個違反構建的提交，但如果你的對分着陸在一個巨大的變化點上，那麼仍然需要解決大量的可能性這可能會導致這個問題，它使平分線的工作變得更加困難。

使用相同的標準來決定是否壓縮合並，因爲您將用於承諾掌握並且您將會確定。

Answer 2

當您想要保留所有的間歇性提交時（例如，分支嘗試某些可能不起作用的情況）時，快進合併很有用。拋開臨時分支比重置工作分支更容易。當實驗工作時，將提交快速轉發到工作分支上是件好事，而不會像實驗一直保留在工作分支上一樣。

我知道沒有理由不將工作提交壓縮成一個全面的提交，幷包含所有更改的消息。正如你所指出的那樣，這樣可以保持歷史的清潔並且更容易處理。從我所看到的，這是保持樹木清潔的首選方法。

git merge --squash使得一個父提交，所以不顯示父連接在被合併。

-A---------C <-- `git merge --squash` 
    \ 
    *--*--B 

另一種選擇是使用git merge --no-ff（沒有快進）來強制合併提交。這個提交將會有父母雙方。優點是保持樹清潔，如果需要仍然有詳細的提交歷史記錄。

-A---------C <-- `git merge --no-ff` 
    \  /
    *--*--B 

兩個C提交相同，選擇後，當你想保持B。