请务必首先熟悉官方《贡献指南》中的代码审查流程。

审查者术语

代码审查中可能会使用一些术语，您应该熟悉它们。

• 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 安全措施，因此很容易覆盖（从而丢失）由不同客户端推送的工作。