大神说：“Showmethecode”，于是就有了codereview。“空谈很便宜。给我看代码。”——LinusTorvalds，Linux和Git的创始人。“Talkischeap.Showmethecode”也存在于代码审查中。语言弱的时候，直接上代码。这就是我们今天要讨论的话题——代码审查中的代码协作。Amailinglist-basedcodereview这是一种与代码仓库松耦合的代码审查模式。100%的代码必须经过一位或多位“仁慈的独裁者”（benevolentdictator）的审核后才能合并到代码库中。这种开发模式也需要开发者掌握一些命令行技巧，才能完成代码在仓库和邮件列表之间的转换。采用这种模式的项目并不多，但Linux和Git开源社区都是按照这种模式运作的。1code和mail的相互转换要将code转换为email，使用gitformat-patch命令。例如，以下命令将指定范围内的代码提交（例如origin/master之后的新提交）转换为电子邮件：gitformat-patchorigin/master..HEAD生成的补丁文件格式如下：From:AuthorNameSubject:[PATCH]firstlineofcommitmessagemorecommitmessage...---diff--git...邮件标题中的Subject:字段是邮件标题，使用[PATCH]作为标题前缀到第一个提交描述的行作为标题内容。更多提交说明作为电子邮件内容，与电子邮件标题由空行分隔。使用分隔符---结束提交指令。分隔符---和由diff--git启动的补丁内容之间的文本将被忽略。通常这里的内容是提交的变更统计，开发者也可以在这里写一些不应该包含在提交说明中的额外说明。gitformat-patch命令的参数较多，应该在不同的场景下使用，例如：一个特征由多个提交组成，分散在多个提交中的提交说明很难描述整个特征。可以使用--cover-letter参数生成一封编号为0000的邮件，作为后续投稿的摘要说明，方便审稿人看懂代码。一个功能通常会迭代多次，每次迭代都需要不同的版本。这需要-v{num}参数来指定补丁的版本。版本会反映在邮件头中，比如补丁的第二个版本，邮件头会使用[PATCHv2]作为前缀。要回复特定消息以形成可跟踪的??消息线程，请使用参数--in-reply-to="{Message-ID}"为电子邮件生成相关的In-Reply-To:和References:标头.默认情况下，提交本身的作者以及提交描述的预告片中提到的贡献者会自动添加为电子邮件的收件人。要添加更多参与者，您可以使用--to={email},--cc={email}参数。要将电子邮件转换为代码，请使用命令gitam[options...]mail...。此命令将正确地将邮件转换为Git存储库中的提交。使用gitsend-email命令将包含代码提交的电子邮件发送到邮件列表。2review中的代码片段转换为提交codereview，通过邮件回复完成。请注意，所有邮件回复都必须是纯文本格式，否则邮件将被邮件服务器退回。如果在codereview中发现一个小的文字错误，比如warning写成warning，reviewer可能会给出如下简洁的回复：s/waring/warning/这种约定俗成的格式大概源于sed命令的语法实现文本替换。审稿人有时会在回复中粘贴一个大的代码补丁。为了区分代码补丁和电子邮件上下文，使用特殊的剪刀分隔符将电子邮件中的评论与代码补丁分开。Subject:Re:whateverthreadyou'reinSomebodyelsesaid:>blahblahblahIdisagree.Youshoulddoitlikethisinstead:-->8--firstlineofcommitmessagemorecommitmessage---diff--git...以上是Peff（JeffKing）在邮件中给出的演示，见是剪刀分离器？剪刀分隔符由多个减号（穿孔的分隔线）和一个剪刀符号组成，构成至少8个字符的分隔符。可选的分隔符是：--8<--,-->8--,--%<--或--->%---等。使用gitam--scissors命令，可以识别邮件中的剪刀分隔符并将邮件中的代码转换为提交。3提交贡献者的签名Git的提交元信息只包含两个签名信息，一个是提交的原作者（Author），一个是将提交合并到仓库或者给提交打补丁的提交者（Committer），以及在投稿审核过程中往往有两个以上的人做出贡献。如何致敬贡献者？Git社区的做法是在提交的最后加上贡献者的签名（预告片）。贡献者签名由被动语态关键字和贡献者ID组成，例如：Signed-off-by:User：通常是代码贡献者（Author）和代码提交者（Committer）提供的签名。可以通过gitcommit-s,gitam-s等命令自动添加。报告者：用户：问题的报告者。Helped-by:User:帮助提交的人。审查者：用户：审查者。您可以通过Git项目存储库的提交历史查看更多签名示例。4使用GitHubPR实现代码到邮件的转换。一个名为GitGitGadget的工具利用GitHub强大的扩展能力，通过向gitgitgadget/git仓库发送pullrequest实现提交到邮件的转换，并发送到Git项目的邮件列表。使用GitGitGadget参与Git社区代码贡献了解详情。2GitHub代码审查中的协作GitHub使用pullrequest进行代码审查，评论中的代码块也可以转化为提交。1Embedcodeblockincodecomments下图中，点击评论工具栏第一个按钮，可以在评论中嵌入代码块：2评论中的代码块转换为提交对pullrequest的源仓库有写权限的用户可以embed将codebaseunderreview转换为commit，如下图所示：一个新的revisioncommit被添加到codereview中。GitHub的这个特性对于codereview中发现的一些小问题非常方便。但大的改变是无能为力的。3离线审查对于功能复杂的pullrequest，在线浏览代码不方便，无法在线调试代码。这时候就非常有必要离线获取和浏览代码了。GitHub的代码仓库为每次代码审查设置了特殊的关联引用：refs/pull/{ID}/head：与pullrequest关联的源代码提交。refs/pull/{ID}/merge：对于没有冲突的拉取请求，此ref指向成功的合并提交。代码审查者可以使用如下命令获取pullrequest指向的commit（例如编号为123的PR）：gitfetchoriginrefs/pull/123/headgitswitch-dFETCH_HEADreviewer可以离线调试pullrequest指向的代码，但是本地没办法直接更新到onlinecodereview。阿里云Codeup支持线下线上代码协同。三云小协同Codeupcodereview不管是GitHub还是Gitlab，开发者创建codereview首先需要将代码推送到一个独立的在线分支（无论是在线派生仓库还是目标仓库），然后通过网页选择源仓库、分支和目标仓库和分支，并创建代码审查。GitHub和Gitlab的代码审查方式要么需要引入冗余的派生仓库，要么需要给予开发者仓库写入权限，容易造成分支管理混乱。1适用于主干开发的BranchlesscodereviewcloudeffectCodeup可以直接在客户端通过gitpush命令创建codereview，无需创建派生仓库或在仓库中创建feature分支。例如在客户端执行如下命令：gitpushoriginHEAD:refs/for/master/topic1这个命令会在服务端创建一个新的codereview，或者如果已经有同一个用户同一个命令创建的codereview，它会更新评论中的提交。建议安装我们开源的git-repo工具，然后您可以使用更简单的命令行从客户端创建/更新代码审查。gitpr2离线审阅，在线协作类似GitHub，云霄Codeup创建的代码审阅有专门关联的引用，格式为：refs/merge-requests/{ID}/head。代码审查人员可以使用gitfetch命令获取特定代码审查指向的代码（以123号为例）进行离线代码审查。gitfetchoriginrefs/merge-requests/123/headgitswitch-dFETCH_HEAD如果安装了git-repo，可以使用下面更简洁的命令：gitdownload123除了浏览和调试本地仓库中的代码，代码审查者还可以更新代码和创建提交。然后更新本地新提交到在线codereview。命令示例如下：gitpr-c123在CloudEffectCodeup中，开发者和审查者可以基于代码审查进行更顺畅的代码协作。3Gitproc-receivehook上述“离线审阅，在线协作”功能的核心是Git的proc-receivehook和新的report-status-v2能力。此功能由阿里巴巴贡献给Git社区，并在Git2.29.0中发布。云霄Codeup汇集了阿里巴巴最新的代码托管和代码协作技术，希望能够造福中国乃至全球更多的开发者。
