請務必首先熟悉官方《貢獻指南》中的程式碼審查流程。

審查者術語

程式碼審查中可能會使用一些術語，您應該熟悉它們。

• LGTM — 我覺得可以（looks good to me）
• SGTM — 我覺得可行（sounds good to me）
• PTAL — 請看一下（please take a look）
• s/foo/bar/ — 請將 foo 替換為 bar；這是 sed 語法
• s/foo/bar/g — 請在您的整個更改中將 foo 替換為 bar

CL 指令

• R=foo — 在 Go CL Dashboard 中指定審查者
• DO NOT SUBMIT（在提交訊息中）— 阻止提交；請參見下文的“進行中的工作”部分
• Updates #1234 或 Fixes #1234（在提交訊息中）— 從 GitHub issue 連結 CL，並在 CL 合併後選擇性地關閉該 issue

電子郵件

程式碼審查的訊息通常會發送到三個地方

• 任何審查者
• golang-codereviews 組
• 所有者

請不要透過電子郵件回覆程式碼審查，因為郵件 將不會轉發到 Gerrit。請務必點選連結並在 Gerrit 中釋出回覆。

進行中的工作

如果您有尚未準備好審查的更改，可以在 CL 描述的第二行寫上巨大的 **DO NOT REVIEW**，這樣看到它的人就會知道不要進一步檢視。不要將其放在第一行，因為那樣它將成為整個審查的主題，即使您更改了描述。

同樣，如果您希望確保您的更改不會被意外合併，可以在 CL 描述的第二行寫上 **DO NOT SUBMIT**。

如果您不需要 Gerrit 的功能，只是想備份您的工作、在多個客戶端之間共享工作，或者有一個暫存 UI 來檢查您的更改，您可以使用常規的 git remote。

要使用 GitHub 作為 git remote，您可以 fork github.com/golang/go 或建立一個新倉庫。兩者都有優缺點。Fork 的倉庫第一次推送速度更快。非 fork 的倉庫可以是私有的。Fork 的倉庫在 GitHub 系統中是關聯的。因此，它們很容易被發現，並且支援 GitHub UI 中的跨倉庫比較；然而，這也意味著 Fork 的倉庫中提交訊息對 issue 的引用將建立對您 Fork 的引用。

要新增您的 git remote，請執行類似以下的命令：

$ git remote add fork git@github.com:yourusername/go.git

然後您可以使用 git push fork branchname 將更改推送到“fork” remote。

Gerrit 的程式碼審查模型是重寫單個提交直到正確。GitHub 會嘗試阻止您意外覆蓋現有分支。您可以透過強制推送來解決此問題：git push --force fork branchname。或者，您可以透過使用以下命令初始克隆來將您的 fork remote 設定為映象：

$ git remote add --mirror=push fork git@github.com:yourusername/go.git

然後執行 git push fork 將更新 GitHub 以完美映象*所有內容*（所有分支、所有標籤等）。這很方便，但請注意在多個客戶端上使用它。您繞過了常規的 git 安全措施，因此很容易覆蓋（從而丟失）由不同客戶端推送的工作。