Go Wiki: 提交訊息
提交訊息，也稱為 CL（更改列表）描述，應按照 https://golang.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 URL 或 git hash，因為這樣更具未來相容性。
- 在儲存庫之間移動程式碼時，請包含 CL、儲存庫名稱和從中/移動到的 git hash，以便更容易追溯歷史/歸因。
請不要使用 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，反之亦然。
Reverts
您可以使用 Gerrit 的 Revert 按鈕回滾更改。Gerrit 會為您生成一個描述。編輯該描述，在 Git 修訂號旁邊或代替它新增要回滾的 Gerrit CL 號。
請勿使用 Gerrit UI 建立對 revert 的 revert，因為這會立即通知相關人員。而是將其作為新更改郵件傳送，並在描述中解釋這是 CL NNNNNN 的向前滾動，而 CL NNNNNN 將其回滾了。
其他儲存庫
對於非“go”儲存庫（“crypto”、“tools”、“net”等），主題仍然是包的名稱，但您需要使用 GitHub org/repo 語法來完全限定問題編號。
cipher/rot13: add new super secure cipher
Fixes golang/go#1234
值得注意的是，第一行主題不應包含 x/crypto/ 字首。我們只在問題跟蹤器中使用它。
非規範性引用
GitHub Pull Requests
如果您使用 GitHub Pull Requests，您的提交訊息將由 GerritBot 根據您的 PR 的標題和描述構建。請參閱 GerritBot 如何確定最終的提交訊息？
如果有人要求您修改提交訊息，您需要修改您的 PR。
此內容是 Go Wiki 的一部分。