提交衛生 是做什麼的？
概述
Jarrett 規則第 4 條：一項變更只包含它邏輯上需要的提交。審查者閱讀的是每個變更的一個乾淨提交，而不是一連串的嘗試紀錄。註解要簡短。
commit-check 鉤子會在 git commit 訊息超出限制時發出警告。它不會阻擋操作，你需要自行修正該提交。
使用時機
- 每次提交前。
- 每次推送前。
- 當你為了修復一個問題而做了多個提交時。
- 當
commit-check鉤子發出警告時。
流程
1. 撰寫訊息
- 主旨：72 個字元或更少。使用祈使語氣：「Add rules hook」（新增規則鉤子），而非「Added rules hook」（已新增規則鉤子）。
- 內文：5 行或更少。若主旨已足夠，則可省略內文。
- 說明變更了什麼以及原因。不要逐一描述每個檔案。
- 使用簡化英語。請參閱
simplified-english技能。
2. 每個邏輯變更製作一個提交
- 一個邏輯變更：審查者可以接受或拒絕的一個功能片斷、一個修復或一個重構，視為一個單位。
- 不要在一個提交中混合重構與行為變更。
- 不要提交每一次嘗試。請在變更成功且測試通過時才提交。
3. 在推送前壓縮修正性提交
修正性提交用於修正同一變更中較早的提交。例如：「fix typo」（修正拼寫錯誤）、「wip」（進行中）、「address review」（處理審查意見）。
- 使用
git commit --fixup <sha>建立修正性提交。 - 不開啟編輯器進行壓縮：
GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash <base>。 - 如果 rebase 因衝突而停止，請修正檔案並執行
git add <files>。然後執行GIT_EDITOR=true git rebase --continue。若要停止，請執行git rebase --abort。 - 再次執行測試。
- 檢查結果：
git log --oneline <base>..HEAD。
若最後一個提交即為需要修正的目標，請使用 git commit --amend --no-edit。
警告：請勿改寫已存在於共用分支上的提交。先詢問使用者。改寫會強迫每位團隊成員重設。
4. 保持註解簡短
- 僅在程式碼不明確時才撰寫註解。
- 一行通常就足夠。說明原因，而非說明什麼。
- 不要在註解中記錄變更歷史。Git 會保留歷史。
常見合理化藉口
| 合理化藉口 | 現實 |
|---|---|
| 「小提交展現我的進度。」 | 審查者需要的是結果，而非過程。請壓縮那些嘗試。 |
| 「長訊息提供更多上下文。」 | 長訊息不會被閱讀。請將上下文放在規格說明或 PR 中。 |
| 「我之後再壓縮。」 | 「之後」就是推送之後。請在推送前壓縮。 |
| 「鉤子只是警告，所以限制是可選的。」 | 限制是團隊規則。鉤子發出警告是為了讓你修正。 |
危險信號
- 推送前
git log顯示「wip」、「fix」、「oops」或「try again」。 - 一個錯誤修正有多個提交。
- 提交內文列出每個被變更的檔案。
- 註解重複說明程式碼已表達的內容。
驗證
- 每個主旨都在 72 個字元或更少，且使用祈使語氣。
- 每個內文都在 5 行或更少。
-
git log --oneline <base>..HEAD顯示每個邏輯變只有一個提交。 - 推送前沒有遺留修正性提交。
- 任何 rebase 後測試皆通過。
已知限制：鉤子不會檢查 git -C <dir> commit 或 git -c <key>=<value> commit。它也會跳過某些無法讀取的訊息，例如 -F <file>。