共计 3877 个字符，预计需要花费 10 分钟才能阅读完成。
简介：代码评审中同样存在着“Talk is cheap. Show me the code”，语言有力时，间接上代码吧。这就是咱们明天要探讨的话题——代码评审中的代码协同。
作者 | 知忧
起源 | 阿里技术公众号
大神说：“Show me the code”，于是就有了代码评审。
“Talk is cheap. Show me the code.”
——Linus Torvalds, founder of Linux and Git.
代码评审中同样存在着“Talk is cheap. Show me the code”，语言有力时，间接上代码吧。这就是咱们明天要探讨的话题——代码评审中的代码协同。
一 基于邮件列表的代码评审
这是一种和代码仓库松耦合的代码评审模式，100% 的代码都要经由一位或多位“善良的独裁者”（benevolent dictator）代码评审后能力合并入代码仓库。这种开发模式还须要开发者把握一些命令行操作技巧以便实现代码在仓库和邮件列表之间的转换。采纳这个模式的我的项目不多，不过 Linux、Git 开源社区就是依照这种模式运作的。
1 代码和邮件的互相转换
代码转换为电子邮件，要应用 git format-patch 命令。例如上面的命令将指定范畴的代码提交（例如在 origin/master 之后的新提交）转换为电子邮件：
git format-patch origin/master..HEAD
生成的补丁文件的格局如下所示：
邮件头中的 Subject: 字段是邮件题目，应用 [PATCH] 作为题目前缀，以提交阐明的第一行作为题目内容。
更多的提交阐明作为邮件内容，和邮件头之间用一个空行分隔开。
用分隔符 — 作为提交阐明的完结。
在分隔符 — 和 diff –git 开始的补丁内容之间的文字被疏忽。通常此处内容是提交的变更统计，开发者也能够在此处写入不宜列入提交阐明中的附加阐明。
git format-patch 命令有很多参数，要联合不同场景应用，例如：
一个个性由多个提交形成，扩散在多个提交中的提交阐明难以描述整个个性，能够应用 –cover-letter 参数，生成一封编号为 0000 的邮件，作为后续提交的摘要阐明，便于评审者了解代码。
一个个性通常会屡次迭代，就须要为每次迭代设置不同的版本。这就要用到 -v {num} 参数指定补丁的版本。版本将体现在邮件题目中，例如第二版本的补丁，邮件题目将应用 [PATCH v2] 作为前缀。
回复特定邮件，以便造成可追踪的邮件线索，应用参数 –in-reply-to=”{Message-ID}”，为电子邮件生成相干的 In-Reply-To: 和 References: 头信息。
默认提交自身的作者、提交阐明的签名区（trailer）提及的贡献者会主动增加为邮件的收件人。要增加更多参与者，能够应用 –to={email}、–cc={email} 参数。
将电子邮件转换为代码，则应用命令 git am [options…] mail…。该命令会将邮件正确转换为 Git 仓库中的提交。
应用 git send-email 命令，将蕴含代码提交的邮件发送到邮件列表。
2 评审中的代码片段转换为提交
代码评审以邮件回复的形式实现。留神邮件回复都要求用纯文本格式，否则会被邮件服务器退信。
代码评审中发现小的文字谬误，例如将 warning 写成了 waring，评审者可能做出如下简洁的回复：
s/waring/warning/
这种约定俗成的格局大略是源于 sed 命令实现文本替换的语法。
评审者有时候会在回复中贴上大段的代码补丁，为了使代码补丁和邮件上下文做出辨别，会应用非凡的剪刀分隔符将邮件中的评论和代码补丁分隔开。
Subject: Re: whatever thread you’re in
Somebody else said:
blah blah blah
I disagree. You should do it like this instead:
— >8 —
first line of commit message
more commit message
diff –git …
下面是 Peff（Jeff King）在邮件中给出的一个示范，看到其中的剪刀分隔符了么？剪刀分隔符由多个减号（穿孔的分割线）和一个剪刀符号组成至多 8 个字符的分隔符。可选的分隔符有：– 8< —、– >8 —、– %< — 或 — >% — 等。
应用 git am –scissors 命令，可能辨认邮件中的剪刀分隔符，将邮件中的代码转换为提交。
3 为提交贡献者署名
Git 的提交元信息中只蕴含两个署名信息，一个是提交的原始作者（Author），一个是将提交合入仓库或者对提交做了修补的提交者（Committer），而在提交评审过程中有过奉献的人往往不只两人，如何致敬贡献者呢？Git 社区的实际是在提交尾部（trailer）增加贡献者签名。贡献者签名由一个被动语态的关键字和贡献者 ID 组成，例如：
Signed-off-by: User < Email >：通常由代码的贡献者（Author）和代码合入时的提交者（Committer）提供的签名。可由命令 git commit -s、git am -s 等命令主动增加。
Reported-by: User < Email >：问题的报告者。
Helped-by: User < Email >：对提交有过帮忙的人。
Reviewed-by: User < Email >：评审者。
能够通过 Git 我的项目仓库的提交历史，看到更多的签名示例。
4 应用 GitHub PR 实现代码到邮件的转换
一个名为 GitGitGadget 工具借助 GitHub 弱小的扩大能力，通过向 gitgitgadget/git 仓库发送 pull request，实现提交到邮件的转换，并发送到 Git 我的项目的邮件列表中。应用 GitGitGadget 参加 Git 社区代码奉献详见。
二 GitHub 代码评审中的协同
GitHub 应用 pull request 进行代码评审，评论中的代码块儿也能够转换为提交。
1 代码评论中嵌入代码块
下图中，点击评论工具栏第一个按钮，能够在评论中嵌入代码块：
2 评论中代码块转换为提交
对 pull request 的源仓库具备写权限的用户，能够将评审中的代码库转换为提交，如下图所示：
于是代码评审中会减少一个新的修改提交。
GitHub 的这个性能对于代码评审中发现的一些小问题，还是十分不便的。然而大的批改就无能为力了。
3 线下评审
对于性能简单的 pull request，在线上浏览代码不不便，也不能线上调试代码，这时线下获取并浏览代码，就十分有必要了。
GitHub 的代码仓库中为每一个代码评审设置了非凡的关联援用：
refs/pull/{ID}/head：关联 pull request 的源提交。
refs/pull/{ID}/merge：对于没有抵触的 pull request，这个援用指向一个胜利的合并提交。
代码评审者应用如下命令能够获取 pull request（例如编号为 123 的 PR）指向的提交：
git fetch origin refs/pull/123/head
git switch -d FETCH_HEAD
评审者能够线下调试 pull request 指向的代码，然而对代码做出的本地批改，没有方法间接更新到线上的代码评审中。
阿里巴巴的云效 Codeup，反对线下到线上的代码协同。
三 云效 Codeup 代码评审中的协同
无论是 GitHub 还是 Gitlab，开发者创立代码评审首先须要将代码推送到线上独立的分支中（无论是在线上的派生仓库，还是指标仓库），而后再通过网页抉择起源仓库、分支及指标仓库、分支，创立代码评审。
GitHub 和 Gitlab 这种代码评审形式，或者要引入冗余的派生仓库，或者须要为开发者赋予在仓库中的写入权限，并容易引发芜杂的分支治理。
1 适宜骨干开发的无分支创立代码评审
云效 Codeup 能够通过 git push 命令在客户端间接创立代码评审，无需创立派生仓库或者在仓库中创立个性分支。例如在客户端执行如下命令：
git push origin HEAD:refs/for/master/topic1
该命令会在服务端创立新的代码评审，或者如果曾经存在雷同用户、雷同命令创立的代码评审则会更新评审中的提交。
倡议装置咱们开源的 git-repo 工具，则能够用更简略的命令行，实现从客户端创立 / 更新代码评审。
git pr
2 线下评审，线上协同
和 GitHub 相似，云效 Codeup 创立的代码评审都有一个非凡援用相关联，格局为：refs/merge-requests/{ID}/head。
代码评审者能够应用 git fetch 命令获取特定的代码评审（以编号 123 为例）指向的代码，进行线下代码评审。
git fetch origin refs/merge-requests/123/head
git switch -d FETCH_HEAD
如果装置了 git-repo，能够应用上面更为简洁的命令：
git download 123
代码评审者除了能够在本地仓库中浏览、调试代码，还能够更新代码、创立提交，而后将本地新增提交更新到线上的代码评审中。命令示例如下：
git pr -c 123
在云效 Codeup，开发者和评审者能够基于代码评审进行更为晦涩的代码协同。
3 Git proc-receive 挂钩
上述“线下评审、线上协同”性能的外围是 Git 的 proc-receive 挂钩和 report-status-v2 新能力。这一性能由阿里巴巴奉献给 Git 社区，并在 Git 2.29.0 公布。
云效 Codeup 会集了阿里巴巴最新的代码托管、代码协同技术，心愿可能造福更多中国和世界的开发者。
原文链接
本文为阿里云原创内容，未经容许不得转载。
