我以前覺得 squash 提交很酷，然後我就不得不每天都使用它們。下面就是你應該避免 squash 的原因。
當我第一次加入一個擁有 200 多名成員的大型工程組織時，我注意到的第一件事就是 squash 提交。
對我來說，整個公司一致使用 squash commits 體現了“專業精神”和“我們知道我們在這裡做什麼！”
我花了大約一個月的時間才意識到我真的不喜歡壓縮提交，並且我開始渴望好的、老式的合併提交。
比較壓縮與合併 Git 提交
需要提醒的是，“壓縮提交”和“合併提交”之間的區別在於，常規“合併”包括目標分支歷史記錄中的所有 Git 提交，而“壓縮”將它們扁平化為一個提交。
令人困惑的是，“squash” 本身並不是命令。相反，您可以在執行git merge或git rebase命令時分別選擇“squash and merge”或“squash and rebase”作為選項。
預設情況下，拉取請求 (PR) 將是合併提交，因此在 PR 合併後，工作分支的整個歷史記錄將合併，外加一個額外的提交（“從分支合併拉取請求 #21...”）。
另一方面，您可以將儲存庫預設設定為“壓縮和合並”，這意味著合併的 PR 將只產生一個提交，而不是從工作分支中帶來所有提交。
為什麼有人會使用 Squash Commits？
壓縮提交的好處是您可以保留“乾淨的” Git 提交歷史記錄。由於我們開發人員以……可以說“精確”而聞名……那麼整潔的提交歷史記錄聽起來絕對很棒。但事實並非如此。
你可以看到為什麼我對他們的專業精神印象深刻——整個工程組織都致力於擁有乾淨的提交歷史，以至於他們強制將“壓縮和合並”作為預設設定！
不幸的是，擁有乾淨的提交歷史的好處就到此為止了 —— 歷史可能是乾淨的，但我的日常工作需要比壓縮提交所能提供的更多的背景資訊。
根據定義，壓縮提交會丟失資訊。我喜歡把它想象成一個黑洞，資訊會變成“霍金輻射”，在這個特定案例中，它是以開發人員的挫敗感為單位來衡量的。
壁球的致命弱點
我很快就對壓縮提交感到失望，原因很簡單，我的工作 90% 是修復舊程式碼中的錯誤。當我使用Git Lens執行檢查一行時git blame，我永遠無法學到所有內容。
公司裡幾乎每個人都git blame 看到“{我的老闆或同事} 提交的合併請求 #237”，沒有其他資訊。如果不手動查詢，我甚至找不到 PR 的主題！真讓人沮喪！
我會盡職盡責地調出原始 PR 和工單，試圖弄清楚為什麼這行程式碼會發生變化，但我卻一無所知。你知道 PR 經常會一次更改數百行程式碼嗎？是的……
我可以用一隻手指數出我需要一次性撤銷整個壓縮提交的次數，而且這是一次戲劇性的 PR 回滾，導致我們的整個路線圖被推遲了整整一個月。
其餘時間，我會做我正常的工作，嘗試在“你能在今天結束前把這個交給 QA 嗎？”的期限內修復錯誤。當我檢查一行程式碼時，我完全不知道它為什麼被修改，因為壓縮提交。
為什麼我不喜歡壓縮我的合併提交
瞧，我也想要一個乾淨的提交歷史，但缺點是會嚴重影響日常工作。雖然知道“修復另一個錯誤時這個錯誤就壞了”很棒，但壓縮提交併不能給我足夠的資訊。
假設我知道我的老闆 18 個月前透過檢查修改了某行程式碼git blame。此時，他肯定不知道為什麼要修改它，即使他能抽出時間為我調查一下。
使用壓縮提交後，我剩下的資訊就更少了：我只能找出導致行被更改的錯誤修復或功能，而不能找出行被更改的實際原因，而這還不足以繼續下去。
雖然如果每一行都有一兩條程式碼註釋那就太好了，但我們都知道大多數開發人員的工作方式並非如此——當我檢視新的 React 程式碼庫時，通常只會看到不到 1％ 的程式碼實際上有任何註釋。
我不知道程式碼更改的原因很簡單；我的老闆當時寫下了原因（在提交訊息中），但後來我們決定毫無理由地“壓制”它。
解決方案是合併提交，而不是壓縮提交
這裡有一個非常簡單的解決方案，它實際上是預設的——只是不要擠壓。我想知道的不多，但它卻帶來了很大的不同：
重構：我的老闆是否“重構”了這段程式碼，使其更具可讀性或可維護性，希望不影響實際功能？
瑣事：我的老闆是否在做一些不應該影響生產程式碼的清理“瑣事”，例如新增程式碼註釋或測試？
修復：我的老闆是否正在“修復”已發現的問題？如果是，這段程式碼具體存在什麼問題？
feat：我的老闆是否正在實施一項新功能，例如建立一個具有面向使用者的功能的全新元件？
您是否意識到這些是常規提交（也稱為“語義提交”），它們最適合與原子提交搭配使用？
我之所以對這家公司如此失望，是因為他們在提交資訊方面的文化很好，但在 PR 方面的文化卻很糟糕。