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

次要版本

如果您想对发布分支进行更改以进行向后移植，请参阅次要版本。