1. 文件
2. 貢獻指南

貢獻指南

Go 專案歡迎所有貢獻者。

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

除了此處的資訊外，Go 社群還維護了一個程式碼審查維基頁面。在學習審查過程時，請隨時為該維基頁面做出貢獻。

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

成為貢獻者

概覽

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

• 第 0 步：選擇一個您將用於貢獻 Go 的 Google 帳號。在以下所有步驟中使用該帳號，並確保已配置 git 以使用該帳號的電子郵件地址建立提交。
• 第 1 步：簽署並提交 CLA（貢獻者許可協議）。
• 第 2 步：配置 Go Git 倉庫的身份驗證憑據。訪問go.googlesource.com，點選頁面右上角選單欄中的“生成密碼”，然後按照說明操作。
• 第 3 步：透過訪問此頁面註冊 Gerrit，這是 Go 團隊使用的程式碼審查工具。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（針對單個特定專案）。您可以使用此命令檢查當前配置：

$ 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，然後點選頁面右上角選單欄中的“生成密碼”。您將被重定向到 accounts.google.com 進行登入。
2. 登入後，您將進入一個標題為“配置 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 團隊尚未決定解決它的最佳方法。最好在編寫程式碼之前等待決定。如果您有興趣處理處於此狀態的問題，如果一段時間沒有決定，請隨時在問題的評論中“提醒”維護人員。
• 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"

為任何新問題開一個 issue

除了非常微不足道的更改外，所有貢獻都應與現有問題相關聯。請隨時開一個 issue 並討論您的計劃。這個過程讓每個人都有機會驗證設計，有助於防止重複工作，並確保想法符合語言和工具的目標。它還在編寫程式碼之前檢查設計是否合理；程式碼審查工具不是進行高層討論的地方。

在規劃工作時，請注意 Go 專案對主要的 Go 倉庫遵循六個月的開發週期。每個週期的後半部分是為期三個月的特性凍結期，在此期間只接受錯誤修復和文件更新。新的貢獻可以在特性凍結期間傳送，但直到凍結結束才能合併。凍結適用於整個主倉庫以及構建釋出中包含的二進位制檔案所需的 golang.org/x/... 倉庫中的程式碼。請參閱標準庫和go 命令中供應商的包列表。

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

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

透過 GitHub 傳送更改

熟悉GitHub 流程的首次貢獻者，建議使用相同的流程進行 Go 貢獻。儘管 Go 維護者使用 Gerrit 進行程式碼審查，但已建立一個名為 Gopherbot 的機器人，用於將 GitHub 拉取請求同步到 Gerrit。

像往常一樣開啟一個 GitHub 拉取請求。Gopherbot 將建立一個相應的 Gerrit 更改列表（一個“CL”）並在您的 GitHub 拉取請求上釋出一個連結；對拉取請求的更新也會反映在 Gerrit CL 中。當有人對 CL 發表評論時，他們的評論也會發布在您的拉取請求中，因此您將收到通知。

需要注意的一些事項：

• 您需要一個Gerrit 帳號才能回覆您的審閱者，包括將反饋標記為“完成”（如果按建議實施）。熟悉 Gerrit 是個好主意，例如透過瀏覽開放的 CL，訂閱有趣的 CL 的更新（透過星形圖示），或審查或給其他人的 CL +1。
• 要用新程式碼更新拉取請求，只需將其推送到分支；您可以新增更多提交，也可以 rebase 並強制推送（兩種方式都接受）。
• 如果請求被接受，所有提交將被壓縮，最終提交描述將由拉取請求的標題和描述連線而成。單個提交的描述將被丟棄。有關建議，請參閱編寫良好的提交訊息。
• 有關更多詳細資訊，請參閱常見問題解答。

透過 Gerrit 傳送更改

目前，Gerrit 和 GitHub 無法完全同步，所以我們建議學習 Gerrit。它有所不同但功能強大，熟悉它將幫助您理解流程。

以下部分簡要介紹了透過 Gerrit 提交更改的步驟。有關與 Gerrit 互動的更多詳細資訊，請參閱Gerrit 的文件。特別是，我們建議閱讀審查 UI 概述和Gerrit 基本操作指南——適用於 GitHub 使用者頁面。

概覽

以下是整體流程概述：

• 第 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 步：審查後，將更改應用於相同的單個提交，並再次將其傳送到 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 工具構建完成，它將作為 bin/go 安裝在您克隆 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 issue 相關，並且您遵循了建議的提交訊息格式，那麼一個機器人將在幾分鐘內更新該 issue，在評論中將您的 Gerrit 更改連結到該 issue。

第 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 issue。絕大多數更改都需要一個關聯的 issue，該 issue 描述了更改修復或實現的錯誤或功能，並且在繼續之前應在跟蹤器上達成共識。Gerrit 審查不討論更改的優點，只討論其實現。
  只有微不足道或純粹的格式更改才會在沒有關聯 issue 的情況下被接受。
• 在開發週期的凍結階段傳送更改，此時樹已關閉以進行一般更改。在這種情況下，維護人員可能會使用諸如 R=go1.12 之類的行審查程式碼，這意味著它將在樹開啟新開發視窗時稍後進行審查。如果您知道這不是更改的正確時間範圍，則可以自己新增 R=go1.XX 作為註釋。

試執行機器人（Trybots）

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

如果試執行機器人執行失敗，請按照連結檢查測試失敗的平臺的完整日誌。嘗試瞭解發生了什麼故障，更新您的補丁以修復它，然後再次上傳。維護者將觸發新的試執行機器人執行以檢視問題是否已修復。

有時，某些平臺上的樹可能會中斷幾個小時；如果試執行機器人報告的故障似乎與您的補丁無關，請轉到構建儀表板並檢查同一故障是否出現在同一平臺上其他最近的提交中。在這種情況下，請隨意在 Gerrit 中寫評論，提及故障與您的更改無關，以幫助維護者瞭解情況。您還可以搜尋 GitHub issue 中失敗的錯誤訊息，或瀏覽最近更新的 watchflakes issue。如果您的更改基於較舊的提交，或者看起來其他人可能已經解決了問題，請嘗試透過 git rebase 重新基於最新的 master 提交。

審查

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

更新更改後，請仔細檢視審查評論並確保回覆每一個。您可以單擊“完成”按鈕來回復，表明您已實施審閱者的建議；否則，單擊“回覆”並解釋您為什麼沒有或您做了什麼。

更改經過幾輪審查是完全正常的，一個或多個審閱者每次都會提出新的評論，然後等待更新的更改才能再次審查。這個迴圈甚至對經驗豐富的貢獻者也會發生，所以不要因此而氣餒。

投票慣例

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

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

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

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

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

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

提交已批准的更改

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

這兩個步驟（批准和提交）是分開的，因為在某些情況下，維護者可能希望批准它但不會立即提交它（例如，樹可能暫時被凍結）。

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

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

更多資訊

除了這裡的資訊，Go 社群還維護了一個程式碼審查維基頁面。在您進一步瞭解審查過程時，請隨意為此頁面做出貢獻。

其他主題

本節收集了許多超出 issue/編輯/程式碼審查/提交過程本身的評論。

Gopls

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

Gopls 的完整文件可在 https://golang.org.tw/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 別名

git-codereview 命令可以直接從 shell 執行，例如，鍵入

$ 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 文件中找到。

次要版本

如果您想對釋出分支進行更改以進行回溯，請參閱次要版本。