Go Wiki：提交訊息
提交訊息，也稱為 CL（變更清單）說明，應依照 https://go.dev.org.tw/doc/contribute#commit_messages 的格式撰寫。例如：，
net/http: handle foo when bar
[longer description here in the body]
Fixes #12345
特別要留意主旨（說明的第一行）
- 受變更影響的套件名稱置於冒號之前
- 冒號之後的部分使用動詞 + 片語，來完成句子「這個變更修改 Go，以 ___________」，使用過去式
- 冒號之後的動詞為小寫
- 尾隨不會有句點
- 應盡量簡短（許多 git 檢視工具比較喜歡 76 個字元以內的內容，儘管 Go 的規定並未那麼嚴格）。
對於本文（說明的其餘部分）
- 文字應換行至約 76 個字元（這主要是為了平息 git 檢視工具的怨言），除非你確實需要使用較長的字行（例如用於 ASCII 藝術、表格或長連結）。
- Fixes 行應放在本文之後，兩者之間以空白換行分隔。（可以使用尾隨句點，例如
Fixes #12345.，但並非必要）。 - 提交訊息中不可使用 Markdown。
- 我們不會使用
Signed-off-by行。請勿新增。我們的 Gerrit 伺服器和 GitHub 機器人會強制執行 CLA 合規性。 - 在參考 CL 時，請優先說「CL nnn」或使用 go.dev/cl/nnn 短連結，而非直接的 Gerrit 網址或 git hash，因為那比較具備永續性。
- 當在儲存庫之間移動程式碼時，請包含從中移動的 CL、儲存庫名稱和 Git 哈希，這樣更容易追蹤歷史記錄/歸咎。
請不要使用 GitHub 支援的其他別名，例如 Close 或 Resolves 取代 Fixes。
若要將提交連結至問題而不標示為已修正（例如，如果提交正在努力修正問題，但尚未完成修正），GitHub 僅要求在提交訊息中按數字提及問題。根據慣例，Go 提交會在訊息底部使用 For 來提及這一點，即使數字也在提交訊息主體中提及，那也可能會是 Fixes。
例如
Refactor func Foo.
This will make the handling of <corner case>
shorter and easier to test.
For #12345
在其他 Git 專案中，使用 Updates 代替 For 很常見，這也可以接受，即使不太有意義（提交並未更新該問題）。更精確的用語也可以。在程式碼檢閱中不要太吹毛求疵：不要要求人們從 Updates 或其他內容變更為 For，反之亦然。
還原
你可以使用 Gerrit Revert 按鈕還原變更。Gerrit 將為你產生說明。編輯說明以加入要還原的 Gerrit CL 編號，放在 Git 修訂編號旁邊或代替它。
不要使用 Gerrit UI 來建立還原的還原，因為那將立即通知別人。相反地，將它傳送為新的變更，並在說明中說明這是 CL NNNNNN 的向前滾動，這已經由 CL NNNNNN 還原。
其他儲存庫
對於非「go」儲存庫（「crypto」、「tools」、「net」，等等），主旨仍然是封裝的名稱，但你需要使用 GitHub 組織/儲存庫語法來完整限定問題號碼
cipher/rot13: add new super secure cipher
Fixes golang/go#1234
值得注意的是，第一行主旨不應包含 x/crypto/ 前綴。我們只對問題追蹤器這樣做。
非規範性參考資料
GitHub Pull Requests
如果你正在使用 GitHub Pull Requests，你的提交訊息將根據你的 PR 標題和說明，由 GerritBot 建立。請參閱 GerritBot 如何確定最終提交訊息？
如果有人要求你修改提交訊息，則你需要修改你的 PR。
此內容是 Go Wiki 的一部分。