大多數人把提交信息當成“留個記號”，能寫“fix bug”絕不多打一個字。這事兒放單人項目里也許湊合，但只要協作一上來，模糊的記錄就會把版本歷史變成考古現場——每位隊友都得拿著鏟子猜“這改動到底在修什么”。實際上，一條清楚的提交信息、一份到位的拉取請求描述，能直接把你的代碼倉庫盤成一本可檢索的團隊文檔。當你在終端里敲下git log時，看到的該是一份有條理的變更說明書，而不是雜亂無章的便條紙。

這種“提交即文檔”的邏輯聽起來有點反直覺，但把它拆開一看，道理非常簡單：一個好的提交歷史，能在三秒內回答三個問題——改了什么、為什么改、跟其他工作怎么關聯。而一份好的拉取請求，則要講清楚解決的是什么問題、用了什么解法、審閱者該把注意力放哪兒。如果你的隊友不用追著你問就能搞明白這些，那這套協作習慣就算立住了。

想讓提交信息一把過，關鍵是套上統一的格式。社區里用得最廣的套路是“約定式提交”（Conventional Commits），它的骨架就一行：

<類型>(可選范圍)：簡短摘要

類型部分用幾個固定標簽把改動意圖標清楚：feat代表新功能， fix修 bug， refactor是只改結構不改行為， chore管依賴、配置這些邊角維護， docs盯文檔， test對應測試。一個實際例子長這樣：

feat(auth): add password reset via email

光有格式還不夠，摘要本身也得節制。一律用現在時——“add”別寫成“added”；掐著大約 72 個字符的寬度寫，保證在日志里不折行；把重點放在“做了什么”，而不是“怎么做的”。比如這種爛例子：

fixed stuff

就完全浪費了閱讀者的時間。好一點的寫法是直接點出具體影響：

fix(cart): prevent duplicate items on rapid click

你看，一行就講清了場景和動作，不用任何人再翻代碼。

有些改動光靠一行說不明白，比如涉及復雜邏輯、邊界處理或取舍的時候，就得上提交正文。正文的結構賊直白，三件事依次交代：這次改動為什么非做不可、選了什么技術路徑、有哪些已知的取舍或極限情況。還是用剛才的例子，當點擊太快導致購物車重復添加時，正文可以這么鋪開：

fix(cart): prevent duplicate items on rapid click用戶在界面還沒刷新前快速點擊，能把同一個商品加進去好幾次。這里的解法是在“添加到購物車”請求還在飛的時候，客戶端先臨時鎖住操作。目前還沒處理服務端的競態情況。

你看，為什么要改、怎么改的、還有哪些坑沒填，一目了然。審閱者看到這里，腦子里已經能畫出改動的邊界了。

另一個提升可追溯性的辦法是把提交跟任務卡片或缺陷單連起來。常見寫法是帶上 Closes #142 或 Fixes PROJ-87 這樣的標記。比如：

feat(search): add fuzzy matching for product names讓用戶拼錯產品名時也能搜出結果來。Closes #142

這么做的好處是，代碼和原始意圖之間打通了一條明線，日后追查“這個功能當初是為了解決哪張票”再也不用猜。

光把單次提交寫漂亮，還只是第一步。一個拉取請求里往往堆了好幾個小提交，怎么把它們合并進主分支，直接影響到歷史可讀性。實際工程里主要就三種策略：壓縮合并、普通合并、變基合并。沒有哪一種絕對正確，看場景選最順手的就行。

壓縮合并（squash and merge）最適合那種小步快跑的特性分支：開發過程里 commit 很多很碎，但合進去時只留一條整齊的記錄。好處是歷史干凈、沒噪音，壞處是丟了細粒度的演進痕跡。普通合并（merge commit）會把分支里所有的提交外加一顆合并提交原封不動保留下來，好處是完整可追溯，復雜特性開發時非常需要這種上下文；但代價就是歷史樹會變得亂糟糟。變基合并（rebase and merge）折了個中：它把提交逐個“搬”到目標分支頂端，不產生合并提交，歷史是一條直線，清清爽爽；可這對團隊的提交紀律要求高，一旦亂用變基改寫過公共歷史，能把隊友的本地倉庫搞得一團亂。

現實中取個巧就行：大部分特性拉取請求安心用 squash，干干凈凈把故事講完；跨了好幾天、多人共管的長分支就用 merge commit，保留全部開發上下文；只有團隊對變基操作已經像呼吸一樣自然的時候，再上 rebase，享受線性歷史的美感。

拉取請求描述這塊，核心就一句話：別讓審閱的人猜。好的描述應該把審閱者當成忙得要死的聰明人，直接把“看哪里”“怎么看”喂給他們。原文對這塊沒展開更多細節，但這條原則本身已經夠用了——去掉所有模棱兩可的敘述，確保打開 PR 的第一屏就能讓人抓到重心，而不是翻完代碼還在心里問“所以這到底解決了啥”。

說到底，寫好提交信息和拉取請求，不是多高深的工程技巧，而是一種給團隊降低認知成本的約定。一旦養成習慣，你會發現自己翻三個月前的代碼時，再也不用對著“update”二字發呆了。