在 Git 中編寫清晰提交歷史的技巧

---

引言

Git 是最重要的工具之一。Git 不僅保留專案的版本歷史，還簡化了團隊間的協作。儘管它是一個非常有價值的工具，但它經常被忽視或未得到充分利用。

清晰的 Git 歷史記錄講述了一個專案的故事，並且易於理解。新增和實現功能的過程一目瞭然。在專案中，我非常重視清晰的 Git 歷史記錄。好訊息是，保持清晰的歷史記錄並不困難。

以下是一些在 Git 中實現清晰歷史記錄的技巧

什麼是 Git 歷史記錄？

Git 表示歷史記錄的方式與 Team Foundation Version Control、Perforce 和 Subversion 等集中式版本控制系統 (CVCS) 表示歷史記錄的方式根本不同。在集中式系統中，儲存庫中的每個檔案都有其自己的歷史記錄。Git 將歷史記錄儲存為對儲存庫在任何給定時間的每個部分的快照的圖表。在 Git 中，這些快照可以有多個父級，從而建立類似圖表的而非線性的歷史記錄。Git 的歷史記錄與 CVCS 截然不同，這是使用者發現它令人困惑的主要原因之一。

有意義的 Git 歷史記錄的重要性

提交訊息是你留在程式碼片段上的指紋。如果你一年後檢視相同的更改，你會感謝你編寫的清晰、有意義的提交訊息，它也會讓你的同事受益。透過上下文隔離提交可以更容易地找到由特定提交引入的錯誤，從而更容易回滾引入錯誤的提交。編寫清晰的提交歷史記錄讓我瞭解到以下幾點。

它促進了拉取請求的審查過程。組織良好的提交可以更好地理解主題。

如果程式碼被組織成小的提交，審查者就不會感到壓力。

審查者用它來發現拉取請求中的錯誤或缺陷。

你將程式碼組織成有意義的提交的方式反映了你對特定問題的理解和方法。

維護清晰 Git 歷史記錄的技巧

以下五個技巧可以幫助你維護清晰的 Git 歷史記錄

始終在分支上工作

使用分支的好處很多。首先，透過在分支而不是主分支上工作，開發人員避免了使用進行中的提交汙染主分支。分支還可以使多個人同時處理一組功能變得更容易。分支的使用有助於將一項功能的工作壓縮成幾個邏輯提交。

遵守並遵循樣式指南

以清晰、描述性的方式描述你的更改將產生的影響。編寫提交訊息時要保持一致（使用祈使句或過去時）。通常，你未來的自己也會閱讀你的提交，因此需要簡要說明其目的。與其寫“修復標題”，不如寫“修復載入 Python DLL 的錯誤”。保持提交訊息少於 50 個字元，因為有人會閱讀你的提交日誌以快速瞭解更改摘要。每個提交都包含你的姓名和日期，因此你無需自己新增它們。它促進了拉取請求的審查過程。組織良好的提交可以更好地理解主題。

練習合併和壓縮

在一個專案中，主分支應該包含高階摘要。應該很容易找到何時以及如何實現功能。為了使功能完全整合，在使用 `git merge --squash` 與主分支合併時，需要再次壓縮它。在合併之前，所有提交都將合併到一個提交中。這很方便，因為所有提交訊息都包含在一個訊息中。

從其他人的角度看待它

對於僅對應用程式有大致瞭解的人來說，理解這組經過良好壓縮的提交應該很容易。在大多數情況下，很難用 50 個字元概括你的工作。只要有可能，根據樣式指南在提交訊息中包含專案符號或段落。將你的寫作視為廣告牌，而不是論文。在將你的程式碼審查功能合併到“master”之前，請徵求他人對你的提交訊息的意見。如果他們能夠快速輕鬆地閱讀和理解你的更改，則表示你成功了。

根據需要刪除分支

分支保留的時間越長，混亂就越多。該分支是否已經合併？是否還有待完成的工作？它是否可能是一個不應該合併的突發事件？

一旦分支完成了它的目的，就刪除它以避免混淆。藉助出色的 Git 擴充套件專案，可以本地和遠端刪除分支。該過程與執行 `git delete-branch ` 一樣簡單。

結論

保持清晰的 Git 歷史記錄需要紀律。如果遵循這些步驟，閱讀專案的歷史記錄就很容易了。你如何維護專案的清晰歷史記錄？