1. 文件
2. 貢獻指南

貢獻指南

Go 專案歡迎所有貢獻者。

本文件旨在指導您完成向 Go 專案貢獻程式碼的流程，這與許多其他開源專案的流程略有不同。我們假設您對 Git 和 Go 有基本的瞭解。

除了此處的資訊外，Go 社群還維護了一個關於程式碼審查的 wiki 頁面。在學習審查流程的同時，歡迎您對該 wiki 頁面做出貢獻。

請注意，gccgo 前端位於其他地方；請參閱貢獻給 gccgo。

成為貢獻者

概覽

第一步是註冊成為 Go 貢獻者並配置您的環境。以下是需要遵循的必要步驟清單

• 步驟 0：確定您將用於貢獻 Go 的單個 Google 帳戶。在所有後續步驟中使用該帳戶，並確保已配置 git，以便使用該帳戶的電子郵件地址建立提交。
• 步驟 1：簽署並提交 CLA（貢獻者許可協議）。
• 步驟 2：配置 Go Git 倉庫的認證憑據。訪問 go.googlesource.com，點選頁面右上角的“Generate Password”（生成密碼），然後按照說明操作。
• 步驟 3：訪問此頁面，註冊 Go 團隊使用的程式碼審查工具 Gerrit。CLA 和註冊只需為您的帳戶完成一次。
• 步驟 4：透過執行 go install golang.org/x/review/git-codereview@latest 安裝 git-codereview

如果您更喜歡，有一個自動化工具可以引導您完成這些步驟。只需執行

$ go install golang.org/x/tools/cmd/go-contrib-init@latest
$ cd /code/to/edit
$ go-contrib-init

本章的其餘部分將詳細闡述這些說明。如果您已完成上述步驟（無論是手動還是透過工具），請跳至貢獻程式碼之前。

步驟 0：選擇一個 Google 帳戶

對 Go 的貢獻是透過具有特定電子郵件地址的 Google 帳戶進行的。請確保在整個過程中以及所有後續貢獻中使用同一帳戶。您可能需要決定使用個人地址還是公司地址。選擇取決於您將編寫和提交的程式碼的版權歸屬方。在決定使用哪個帳戶之前，您可能希望與您的僱主討論此問題。

Google 帳戶可以是 Gmail 電子郵件帳戶、G Suite 組織帳戶，或關聯外部電子郵件地址的帳戶。例如，如果您需要使用一個未透過 G Suite 管理的現有公司電子郵件，您可以建立與您的現有電子郵件地址關聯的帳戶。

您還需要確保已配置您的 Git 工具，以便使用您選擇的電子郵件地址建立提交。您可以全域性配置 Git（作為所有專案的預設設定），或本地配置（針對單個特定專案）。您可以使用此命令檢查當前配置

$ git config --global user.email  # check current global config
$ git config user.email           # check current local config

要更改配置的地址

$ git config --global user.email name@example.com   # change global config
$ git config user.email name@example.com            # change local config

步驟 1：貢獻者許可協議

在向 Go 專案傳送您的第一個變更之前，您必須完成以下兩個 CLA 之一。您應該簽署哪個 CLA 取決於您工作的版權歸屬方。

• 如果您是版權持有人，您需要同意個人貢獻者許可協議，該協議可以線上完成。
• 如果您的組織是版權持有人，該組織將需要同意公司貢獻者許可協議。
  

您可以在 Google 開發者貢獻者許可協議網站上檢視您當前已簽署的協議並簽署新協議。如果您的貢獻的版權持有人已經與另一個 Google 開源專案完成了協議，則無需再次完成。

如果您提交的程式碼的版權持有人發生變更——例如，如果您開始代表一家新公司貢獻程式碼——請傳送電子郵件至golang-dev 郵件列表。這將讓我們瞭解情況，以便我們確保完成適當的協議。

步驟 2：配置 git 認證

主要的 Go 倉庫位於 go.googlesource.com，這是一個由 Google 託管的 Git 伺服器。Web 伺服器上的認證透過您的 Google 帳戶完成，但您還需要在您的計算機上配置 git 以訪問它。請按照以下步驟操作

1. 訪問 go.googlesource.com 並點選頁面右上角的“Generate Password”（生成密碼）。您將被重定向到 accounts.google.com 進行登入。
2. 登入後，您將進入一個標題為“Configure Git”（配置 Git）的頁面。該頁面包含一個個性化指令碼，在本地執行時將配置 Git 以儲存您的唯一認證金鑰。此金鑰與伺服器上生成和儲存的金鑰配對，類似於 SSH 金鑰的工作方式。
3. 在您的終端中複製並本地執行此指令碼，將您的秘密認證令牌儲存在 .gitcookies 檔案中。如果您使用的是 Windows 計算機並執行 cmd，則應轉而按照黃色框中的說明執行命令；否則執行常規指令碼。

步驟 3：建立一個 Gerrit 帳戶

Gerrit 是 Go 維護者用於討論和審查程式碼提交的開源工具。

要註冊您的帳戶，請訪問 go-review.googlesource.com/login/ 並使用您上面使用的同一 Google 帳戶登入一次。

步驟 4：安裝 git-codereview 命令

無論由誰做出更改，對 Go 的更改都必須先經過審查才能接受。一個名為 git-codereview 的自定義 git 命令簡化了將更改傳送到 Gerrit 的過程。

透過執行以下命令安裝 git-codereview 命令：

$ go install golang.org/x/review/git-codereview@latest

確保 git-codereview 已安裝在您的 shell 路徑中，以便 git 命令能夠找到它。檢查

$ git codereview help

列印的是幫助文字，而不是錯誤。如果它列印錯誤，請確保 $GOPATH/bin 在您的 $PATH 中。

在 Windows 上使用 git-bash 時，必須確保 git-codereview.exe 在您的 git exec-path 中。執行 git --exec-path 查詢正確的位置，然後建立符號連結或直接將可執行檔案從 $GOPATH/bin 複製到此目錄。

貢獻程式碼之前

專案歡迎程式碼補丁，但為了確保工作協調良好，您應該在開始工作之前討論任何重要的變更。建議您透過提交新問題或認領現有問題來在問題跟蹤器中表明您的貢獻意向。

貢獻到哪裡

Go 專案由主要的 go 倉庫組成，其中包含 Go 語言的原始碼，以及許多 golang.org/x/... 倉庫。這些倉庫包含支援 Go 的各種工具和基礎設施。例如，golang.org/x/pkgsite 用於 pkg.go.dev，golang.org/x/playground 用於 Go playground，而 golang.org/x/tools 包含各種 Go 工具，包括 Go 語言伺服器 gopls。您可以在 go.googlesource.com 上檢視所有 golang.org/x/... 倉庫的列表。

檢查問題跟蹤器

無論您已知要做出何種貢獻，還是正在尋找想法，問題跟蹤器始終是首選之地。問題會被分類並管理其工作流程。

大多數 golang.org/x/... 倉庫也使用主 Go 問題跟蹤器。然而，其中少數倉庫獨立管理其問題，因此請確保檢查您希望貢獻的倉庫對應的跟蹤器。

大多數問題將標記以下工作流標籤之一

• NeedsInvestigation（需要調查）：問題尚未完全理解，需要進行分析以瞭解根本原因。
• NeedsDecision（需要決策）：問題已相對清晰，但 Go 團隊尚未決定最佳解決方式。在編寫程式碼之前最好等待決策。如果您對處理處於此狀態的問題感興趣，如果一段時間沒有決策，歡迎在問題的評論中“ping”維護者。
• NeedsFix（需要修復）：問題已完全理解，可以編寫程式碼進行修復。

您可以使用 GitHub 的搜尋功能查詢需要幫助的問題。例如

• 需要調查的問題：is:issue is:open label:NeedsInvestigation
• 需要修復的問題：is:issue is:open label:NeedsFix
• 需要修復並有建議變更的問題：is:issue is:open label:NeedsFix ("golang.org/cl" OR "go.dev/cl")
• 需要修復但沒有建議變更的問題：is:issue is:open label:NeedsFix NOT "golang.org/cl" NOT "go.dev/cl"

為任何新問題提交問題

除了非常微不足道的更改外，所有貢獻都應與現有問題關聯。歡迎提交一個問題並討論您的計劃。此過程讓每個人都有機會驗證設計，有助於防止重複工作，並確保想法符合語言和工具的目標。它還可在編寫程式碼之前檢查設計的合理性；程式碼審查工具不適用於高層次的討論。

規劃工作時，請注意 Go 專案的主 Go 倉庫遵循六個月的開發週期。每個週期的後半部分是為期三個月的功能凍結期，在此期間只接受 bug 修復和文件更新。在功能凍結期間可以傳送新的貢獻，但在凍結期結束之前不會合並。凍結適用於整個主倉庫以及構建版本中包含的二進位制檔案所需的 golang.org/x/... 倉庫中的程式碼。請參閱引入到標準庫和go 命令中的包列表。

對語言、庫或工具的重大變更（包括主倉庫和所有 golang.org/x 倉庫中的 API 變更，以及 go 命令的命令列變更）必須先經過變更提案流程才能接受。

敏感的安全相關問題（僅限！）應報告至 security@golang.org。

透過 GitHub 傳送變更

已熟悉 GitHub flow 的首次貢獻者被鼓勵在 Go 貢獻中使用相同的流程。儘管 Go 維護者使用 Gerrit 進行程式碼審查，但已建立了一個名為 Gopherbot 的機器人來將 GitHub pull requests 同步到 Gerrit。

像往常一樣建立 GitHub pull request。Gopherbot 將建立相應的 Gerrit 變更列表（"CL"），並在您的 GitHub pull request 上釋出連結；對 pull request 的更新也會反映在 Gerrit CL 中。當有人在 CL 上評論時，他們的評論也會發布到您的 pull request 中，這樣您就會收到通知。

需要注意的事項

• 您需要一個 Gerrit 帳戶來回複審閱者，包括如果按照建議實施，需要將反饋標記為“Done”。熟悉 Gerrit 是個好主意，例如透過瀏覽未決的 CL，訂閱感興趣的 CL 的更新（透過星形圖示），或審查或為他人的 CL 點贊 (+1)。
• 要用新程式碼更新 pull request，只需將其推送到分支；您可以新增更多提交，或者進行 rebase 並強制推送（兩種方式均可接受）。
• 如果請求被接受，所有提交將被 squash 合併，最終提交的描述將由 pull request 的標題和描述連線組成。單個提交的描述將被丟棄。有關建議，請參閱編寫好的提交訊息。
• 有關更多詳細資訊，請參閱常見問題。

透過 Gerrit 傳送變更

目前至少無法完全同步 Gerrit 和 GitHub，因此我們建議學習 Gerrit。它不同尋常但功能強大，熟悉它將有助於您理解流程。

概覽

以下是整個流程的概覽

• 步驟 1：從 go.googlesource.com 克隆原始碼，並透過編譯和測試一次確保其穩定。

  如果您正在更改 主 Go 倉庫

  $ git clone https://go.googlesource.com/go
  $ cd go/src
  $ ./all.bash                                # compile and test
  

  如果您正在更改某個 golang.org/x/... 倉庫（本例中為 golang.org/x/tools）

  $ git clone https://go.googlesource.com/tools
  $ cd tools
  $ go test ./...                             # compile and test
  

• 步驟 2：在基於 master 分支建立的新分支中準備更改。要提交更改，請使用 git codereview change；這將在分支中建立或修改單個提交。

  $ git checkout -b mybranch
  $ [edit files...]
  $ git add [files...]
  $ git codereview change   # create commit in the branch
  $ [edit again...]
  $ git add [files...]
  $ git codereview change   # amend the existing commit with new changes
  $ [etc.]
  

• 步驟 3：測試您的更改，可以執行您編輯的包中的測試，或重新執行 all.bash。

  在主 Go 倉庫中

  $ ./all.bash    # recompile and test
  

  在 golang.org/x/... 倉庫中

  $ go test ./... # recompile and test
  

• 步驟 4：使用 git codereview mail（儘管名稱如此，但不使用電子郵件）將更改傳送到 Gerrit 進行審查。

  $ git codereview mail     # send changes to Gerrit
  

• 步驟 5：審查後，將更改應用到同一單個提交中，並再次透過 mail 傳送到 Gerrit

  $ [edit files...]
  $ git add [files...]
  $ git codereview change   # update same commit
  $ git codereview mail     # send to Gerrit again
  

本節的其餘部分將更詳細地描述這些步驟。

步驟 1：克隆原始碼

除了最新的 Go 安裝之外，您還需要從正確的倉庫檢出原始碼的本地副本。您可以將 Go 原始碼倉庫檢出到您本地檔案系統的任何位置，只要它不在您的 GOPATH 中（預設是主目錄下的 go 目錄）。從 go.googlesource.com（而非 GitHub）克隆

主 Go 倉庫

$ git clone https://go.googlesource.com/go
$ cd go

golang.org/x/... 倉庫

$ git clone https://go.googlesource.com/tools
$ cd tools

步驟 2：在新分支中準備更改

每個 Go 變更必須在單獨的分支中進行，該分支基於 master 分支建立。您可以使用常規的 git 命令建立分支並將更改新增到暫存區

$ git checkout -b mybranch
$ [edit files...]
$ git add [files...]

要提交更改，請使用 git codereview change，而不是 git commit。

$ git codereview change
(open $EDITOR)

您可以像往常一樣在您喜歡的編輯器中編輯提交描述。git codereview change 命令會自動在底部附近新增一個唯一的 Change-Id 行。該行由 Gerrit 用於匹配同一更改的後續上傳。請勿編輯或刪除它。Change-Id 看起來像這樣

Change-Id: I2fbdbffb3aab626c4b6f56348861b7909e3e8990

該工具還會檢查您是否對原始碼運行了 go fmt，並且提交訊息遵循建議的格式。

如果需要再次編輯檔案，可以暫存新的更改並重新執行 git codereview change：每次後續執行都會修改現有提交，同時保留 Change-Id。

確保每個分支中始終只保留一個提交。如果您不小心添加了更多提交，可以使用 git rebase 將它們合併為一個。

步驟 3：測試您的更改

您已經編寫並測試了您的程式碼，但在將程式碼傳送出去進行審查之前，請執行整個程式碼樹的所有測試，以確保更改不會破壞其他包或程式。

在主 Go 倉庫中

對於標準庫包，包內的所有測試都必須透過

$ go test

可以使用 all.bash 執行整個程式碼樹的簡短測試套件（在 Windows 下構建請使用 all.bat）

$ cd go/src
$ ./all.bash

執行一段時間並列印大量測試輸出後，命令應以下列內容結束：

ALL TESTS PASSED

您可以使用 make.bash 而不是 all.bash 來僅構建編譯器和標準庫而不執行測試套件。一旦構建了 go 工具，它將安裝在您克隆 Go 倉庫的目錄下的 bin/go，您可以直接從那裡執行它。另請參閱關於如何快速測試您的更改的部分。

在 golang.org/x/... 倉庫中

執行整個倉庫的測試（本例中為 golang.org/x/tools）

$ cd tools
$ go test ./...

如果您擔心構建狀態，可以檢視構建面板。測試失敗也可能被程式碼審查中的 TryBots 捕獲。

一些倉庫，例如 golang.org/x/vscode-go 將擁有不同的測試基礎設施，因此請始終檢視您正在工作的倉庫的文件。倉庫根目錄下的 README 檔案通常會包含此資訊。

步驟 4：傳送更改進行審查

更改準備好並經過整個程式碼樹測試後，即可傳送進行審查。這透過 mail 子命令完成，該子命令儘管名稱如此，但並不直接傳送任何郵件；它只是將更改傳送到 Gerrit

$ git codereview mail

Gerrit 會為您的更改分配一個編號和 URL，git codereview mail 將會打印出來，類似於

remote: New Changes:
remote:   https://go-review.googlesource.com/99999 math: improved Sin, Cos and Tan precision for very large arguments

如果您反而收到錯誤，請檢視郵件錯誤排查部分。

如果您的更改與一個未解決的 GitHub 問題相關，並且您遵循了建議的提交訊息格式，該問題將在幾分鐘內由機器人更新，在評論中連結您的 Gerrit 更改。

步驟 5：審查後修改更改

Go 維護者將在 Gerrit 上審查您的程式碼，您將透過電子郵件收到通知。您可以在 Gerrit 上檢視審查並發表評論。如果您願意，也可以使用電子郵件回覆。

如果在審查後需要修改您的更改，請在您之前建立的同一分支中編輯檔案，將它們新增到 Git 暫存區，然後使用 git codereview change 修改提交

$ git codereview change     # amend current commit
(open $EDITOR)
$ git codereview mail       # send new changes to Gerrit

如果您不需要更改提交描述，只需儲存並退出編輯器。請記住不要更改特殊的 Change-Id 行。

再次強調，請確保每個分支中始終只保留一個提交。如果您不小心添加了更多提交，可以使用 git rebase 將它們合併為一個。

好的提交訊息

Go 中的提交訊息遵循一套特定的約定，我們將在本節中討論。

以下是一個好的提交訊息示例

math: improve Sin, Cos and Tan precision for very large arguments

The existing implementation has poor numerical properties for
large arguments, so use the McGillicutty algorithm to improve
accuracy above 1e10.

The algorithm is described at https://wikipedia.org/wiki/McGillicutty_Algorithm

Fixes #159

第一行

變更描述的第一行通常是該變更的簡短單行摘要，並以主要受影響的包作為字首。

一個經驗法則是，它應該寫成能夠完成句子“此變更修改 Go 以 _____。”這意味著它不以大寫字母開頭，不是一個完整的句子，並且實際總結了變更的結果。

在第一行之後留一個空行。

主要內容

其餘描述進行詳細闡述，應提供更改的背景並解釋其作用。像在 Go 中編寫註釋一樣，使用帶有正確標點的完整句子進行編寫。不要使用 HTML、Markdown 或任何其他標記語言。

新增任何相關資訊，例如如果更改影響效能，則新增基準測試資料。通常使用 benchstat 工具來格式化用於變更描述的基準測試資料。

引用問題

特殊標記“Fixes #12345”將該變更與Go 問題跟蹤器中的問題 #12345 相關聯。當此變更最終應用時，問題跟蹤器將自動將該問題標記為已修復。

如果更改是解決問題過程中的一個部分步驟，請改為寫“Updates #12345”。這將在問題中留下一個評論，連結回 Gerrit 中的更改，但不會在更改應用時關閉問題。

如果您正在針對 golang.org/x/... 倉庫傳送更改，必須使用 GitHub 支援的完全限定語法，以確保更改連結到主倉庫中的問題，而不是 x/ 倉庫。大多數問題在主倉庫的問題跟蹤器中進行跟蹤。正確的形式是“Fixes golang/go#159”。

審查流程

本節詳細解釋了審查流程以及在變更傳送後如何處理審查。

常見的初學者錯誤

當更改傳送到 Gerrit 後，通常會在幾天內進行分類。維護者會檢視並提供一些初步審查，對於首次貢獻者來說，通常側重於基本的格式和常見錯誤。這些包括如下事項：

• 提交訊息未遵循建議的格式。
• 缺少關聯的 GitHub 問題。絕大多數更改需要關聯一個描述更改修復或實現 bug 或功能的 issue，並且在繼續之前應已在跟蹤器上達成共識。Gerrit 審查不討論更改本身的價值，只討論其實現。
  只有微不足道或僅進行格式更改的更改才可以在沒有關聯 issue 的情況下接受。
• 在開發週期的凍結階段（此時程式碼樹不對一般更改開放）傳送的更改。在這種情況下，維護者可能會用一行諸如 R=go1.12 的文字來審查程式碼，這意味著將在新的開發視窗開啟後進行審查。如果您知道該更改不在正確的時間範圍內，可以自己新增 R=go1.XX 作為評論。

Trybots

在初步閱讀您的更改後，維護者會觸發 trybots，這是一個伺服器叢集，將在多種不同架構上執行完整的測試套件。大多數 trybots 在幾分鐘內完成，屆時將在 Gerrit 中釋出一個連結，您可以在其中檢視結果。

如果 trybot 執行失敗，請點選連結並檢查測試失敗的平臺的完整日誌。嘗試理解是什麼導致了問題，更新您的補丁來修復它，然後再次上傳。維護者將觸發新的 trybot 執行以檢視問題是否已修復。

有時，某些平臺上的程式碼樹可能會損壞幾個小時；如果 trybot 報告的失敗似乎與您的補丁無關，請前往構建面板，檢查同一平臺上的其他最近提交中是否出現相同的失敗。在這種情況下，歡迎在 Gerrit 中撰寫評論提及該失敗與您的更改無關，以幫助維護者理解情況。您還可以搜尋 GitHub issue 以查詢失敗的錯誤訊息，或瀏覽最近更新的 watchflakes 問題。如果您的更改基於較舊的提交，或者看起來其他人可能已經解決了該問題，請嘗試透過 git rebase rebase 到最新的 master 提交。

審查

Go 社群非常重視徹底的審查。將每個審查評論視為一張工單：您需要透過對其採取行動來“關閉”它，要麼實施建議，要麼說服審閱者另作處理。

更新更改後，請仔細檢視審查評論，並確保回覆每一個評論。您可以點選“Done”按鈕回覆，表明您已實施了審閱者的建議；否則，點選“Reply”並解釋您為何沒有實施，或您採取了什麼其他措施。

更改經過多輪審查是完全正常的，每次審查者都會提出新的評論，然後等待更新後的更改再次進行審查。這個迴圈即使對於經驗豐富的貢獻者也會發生，因此請不要因此感到沮喪。

投票約定

當接近決策時，審閱者將對您的更改應用 Code-Review “投票”。有兩種可能的投票

• +2：更改批准合併。只有 Go 維護者（也稱為“批准者”）可以投 +2 票。
• +1：更改看起來不錯，但審閱者在批准之前要求進行少量修改，或者他們不是維護者，無法批准，但希望鼓勵批准。

要提交，更改必須獲得維護者的 Code-Review +2 投票。

維護者還可以對更改應用 Hold +1 投票，以標記暫時不應提交的更改（例如，因為更改中新 API 的提案審查尚未完成）。

要提交，更改不得有任何維護者的 Hold +1 投票。

最後，要提交，更改必須有兩名 Google 員工參與，無論是作為更改的上傳者還是作為至少投 Code-Review +1 票的審閱者。此要求是出於合規性和供應鏈安全考慮。

提交已批准的更改

更改準備就緒後，維護者將提交更改，將其作為提交新增到 Gerrit 倉庫。

批准和提交這兩個步驟是分開的，因為在某些情況下，維護者可能希望批准更改但不想立即提交（例如，程式碼樹可能暫時處於凍結狀態）。

提交更改會將其簽入倉庫。更改描述將包含指向程式碼審查的連結，該連結將更新為指向倉庫中更改的連結。由於用於整合更改的方法是 Git 的“Cherry Pick”，因此倉庫中的提交雜湊將在提交操作後發生變化。

如果您的更改已批准幾天但尚未提交，請隨時在 Gerrit 中撰寫評論請求提交。

更多資訊

除了此處的資訊外，Go 社群還維護了一個關於程式碼審查的 wiki 頁面。在您更深入地瞭解審查流程時，歡迎對該頁面做出貢獻。

雜項主題

本節收集了一些其他評論，這些評論超出了問題/編輯/程式碼審查/提交流程本身。

Gopls

在主 Go 倉庫中工作並使用編輯器配合 gopls 時，由 gopls 呼叫的 go 命令必須與您正在處理的原始碼版本對應。可以使用 make.bash 構建 go 命令，並且應將 bin 目錄新增到您的 PATH 中。有關更多詳細資訊，請參閱 Gopls：高階主題。

版權頭部

Go 倉庫中的檔案不列出作者姓名，這樣做既可以避免混亂，也可以避免不斷更新列表。相反，您的姓名將出現在變更日誌中。

您貢獻的新檔案應使用標準的版權頭部

// Copyright 2025 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

倉庫中的檔案在其添加當年享有版權。請勿更新您更改的檔案的版權年份。

郵件錯誤排查

最常見的 git codereview mail 命令失敗原因是提交中的電子郵件地址與您在註冊過程中使用的地址不匹配。
如果您看到類似以下內容...

remote: Processing changes: refs: 1, done
remote:
remote: ERROR:  In commit ab13517fa29487dcf8b0d48916c51639426c5ee9
remote: ERROR:  author email address XXXXXXXXXXXXXXXXXXX
remote: ERROR:  does not match your user account.

您需要為這個倉庫配置 Git，使其使用您註冊時使用的電子郵件地址。要更改電子郵件地址以確保不再發生這種情況，請執行

$ git config user.email email@address.com

然後使用此命令更改提交，使其使用此備用電子郵件地址

$ git commit --amend --author="Author Name <email@address.com>"

然後透過執行以下命令重試

$ git codereview mail

快速測試您的更改

每次對程式碼樹進行更改時都執行 all.bash 是一件繁瑣的事情。雖然強烈建議在傳送更改之前執行它，但在正常的開發週期中，您可能只想編譯和測試您正在開發的包。

• 一般來說，您可以執行 make.bash 代替 all.bash，這樣只重建 Go 工具鏈，而不執行整個測試套件。或者您可以執行 run.bash，這樣只執行整個測試套件，而不重建工具鏈。您可以將 all.bash 視為 make.bash 後接 run.bash。
• 在本節中，我們將您克隆 Go 倉庫的目錄稱為 $GOROOT。由 $GOROOT/src/make.bash 構建的 go 工具將安裝在 $GOROOT/bin/go 中，您可以呼叫它來測試您的程式碼。例如，如果您修改了編譯器並想測試它如何影響您自己專案的測試套件，只需使用它執行 go test

  $ cd <MYPROJECTDIR>
  $ $GOROOT/bin/go test
  

• 如果您正在更改標準庫，您可能不需要重新構建編譯器：您只需執行您更改的包的測試即可。您可以使用您通常使用的 Go 版本來執行此操作，或使用從您的克隆構建的 Go 編譯器（有時需要這樣做，因為您正在修改的標準庫程式碼可能需要比您安裝的穩定版本更新的版本）。

  $ cd $GOROOT/src/crypto/sha1
  $ [make changes...]
  $ $GOROOT/bin/go test .
  

• 如果您正在修改編譯器本身，您只需重新編譯 compile 工具（它是 go build 呼叫用於編譯每個包的內部二進位制檔案）。之後，您將希望透過編譯或執行一些東西來測試它。

  $ cd $GOROOT/src
  $ [make changes...]
  $ $GOROOT/bin/go install cmd/compile
  $ $GOROOT/bin/go build [something...]   # test the new compiler
  $ $GOROOT/bin/go run [something...]     # test the new compiler
  $ $GOROOT/bin/go test [something...]    # test the new compiler
  

  這同樣適用於 Go 工具鏈的其他內部工具，例如 asm、cover、link 等等。只需使用 go install cmd/<TOOL> 重新編譯並安裝該工具，然後使用構建好的 Go 二進位制檔案來測試它。
• 除了標準的按包測試外，在 $GOROOT/test 中還有一個頂層測試套件，其中包含多個黑盒和迴歸測試。測試套件由 all.bash 執行，但您也可以手動執行它

  $ $GOROOT/bin/go test cmd/internal/testdir
  

指定審閱者 / 抄送他人

除非另有明確說明（例如在提交更改前的討論中），否則最好不要指定審閱者。所有更改都會自動抄送至 golang-codereviews@googlegroups.com 郵件列表。如果這是您的第一次更改，可能會出現稽核延遲，然後才能在郵件列表上顯示，以防止垃圾郵件。

您可以使用 -r 或 -cc 選項指定審閱者或抄送相關方。兩者都接受逗號分隔的電子郵件地址列表

$ git codereview mail -r joe@golang.org -cc mabel@example.com,math-nuts@swtch.com

同步您的客戶端

在您工作期間，其他人可能已向倉庫提交了更改。要更新您的本地分支，請執行

$ git codereview sync

（在內部，這會執行 git pull -r。）

審閱他人的程式碼

作為審閱過程的一部分，審閱者可以直接提出更改（在 GitHub 工作流程中，這將是其他人將提交附加到拉取請求）。Gerrit 提供了命令，可以幫助您匯入其他開發者提出的更改，以便您在本地審閱/測試它們。在您要匯入的 CL 的 Gerrit 頁面上，開啟“⋮”選單，點選“下載補丁”連結。根據您偏好的 git 工作流程，選擇適當的命令。選項看起來會像這樣

$ git fetch https://go.googlesource.com/review refs/changes/21/13245/1 && git checkout FETCH_HEAD

要還原，請切換回您正在工作的分支。

設定 Git 別名

例如，可以直接在 shell 中輸入 git-codereview 命令來執行它：

$ git codereview sync

但更方便的是為 git-codereview 自己的子命令設定別名，這樣上面的命令就變成了：

$ git sync

git-codereview 的子命令被選擇與 Git 自己的子命令不同，因此定義這些別名是安全的。要安裝它們，請將以下文字複製到您的 Git 配置檔案中（通常是您主目錄中的 .gitconfig）

[alias]
	change = codereview change
	gofmt = codereview gofmt
	mail = codereview mail
	pending = codereview pending
	submit = codereview submit
	sync = codereview sync

傳送多個依賴的更改

高階使用者可能希望在單個分支中堆疊相關的提交。Gerrit 允許更改相互依賴，從而形成此類依賴鏈。每個更改都需要單獨批准和提交，但依賴關係對審閱者可見。

要傳送一組依賴的更改，請將每個更改作為同一分支下的不同提交保留，然後執行

$ git codereview mail HEAD

確保明確指定 HEAD，這在傳送單個更改時通常不需要。更多詳細資訊可以在 git-codereview 文件中找到。

次要版本

如果您想對釋出分支進行更改以進行向後移植，請參閱次要版本。