介绍：在codereview中，也有“Talkischeap.Showmethecode”。语言弱的时候，直接上传代码就好了。这就是我们今天要讨论的话题——代码审查中的代码协作。作者|知道忧虑的来源|阿里技术大师公众号说：“Showmethecode”，于是就有了codereview。“空谈很便宜。给我看代码。”——LinusTorvalds，Linux和Git的创始人。“Talkischeap.Showmethecode”也存在于代码审查中。语言弱的时候，直接上代码。这就是我们今天要讨论的话题——代码审查中的代码协作。1.基于邮件列表的代码审查这是一种与代码仓库松耦合的代码审查模式。100%的代码必须经过一位或多位“仁慈的独裁者”（benevolentdictator）的审核后才能合并到代码库中。这种开发模式也需要开发者掌握一些命令行技巧，才能完成代码在仓库和邮件列表之间的转换。采用这种模式的项目并不多，但Linux和Git开源社区都是按照这种模式运作的。1code和mail的相互转换要将code转换为email，使用gitformat-patch命令。例如，以下命令将指定范围内的代码提交（例如origin/master之后的新提交）转换为电子邮件：gitformat-patchorigin/master..HEAD生成的补丁文件格式如下：主题：字段为邮件主题，使用[PATCH]作为主题前缀，提交描述的第一行作为主题内容。更多提交说明作为电子邮件内容，与电子邮件标题由空行分隔。使用分隔符---结束提交指令。分隔符---和由diff--git启动的补丁内容之间的文本将被忽略。通常这里的内容是提交的变更统计，开发者也可以在这里写一些不应该包含在提交说明中的额外说明。gitformat-patch命令的参数比较多，需要结合不同的场景使用。比如一个feature是由多个submission组成，分散在多个submission中的提交说明很难描述整个feature。可以使用--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命令的语法实现文本替换。审稿人有时会在回复中粘贴一个大的代码补丁。为了区分代码补丁和电子邮件上下文，使用特殊的剪刀分隔符将电子邮件中的评论与代码补丁分开。主题：回复：无论你在哪个线程其他人说：blahblahblah我不同意。你应该这样做：-->8--firstlineofcommitmessagemorecommitmessagediff--git...上面是一封电子邮件中的Peff(JeffKing)，看到剪刀分隔符了吗？剪刀分隔符是至少8个字符的分隔符，由多个减号（穿孔分隔线）和一个剪刀符号组成。可选的分隔符是：--8<--、-->8--、--%<--或--->%---等。使用gitam--scissors命令，可以识别邮件中的剪刀分隔符并将邮件中的代码转换为提交。3Git的提交元信息只包含两个签名信息，一个是提交的原作者（Author），一个是将提交合并到仓库或者给提交打补丁的提交者（Committer）。在投稿审核过程中往往有两个以上的人做出贡献。如何致敬贡献者？在Git社区中，将贡献者的签名添加到提交预告片中是一种惯例。贡献者签名由被动语态关键字和贡献者ID组成，例如：Signed-off-by:User
