如果有什么我讨厌的东西，那就是当我知道我可以自动化它们时，但我手动进行了操作。只有我有这种情况么？我觉得不是。

尽管如此，他们每天都有数千名使用 GitHub 的开发人员一遍又一遍地做同样的事情：他们点击这个按钮：

这没有任何意义。

不要误解我的意思。合并拉取请求是有意义的。只是每次点击这个该死的按钮是没有意义的。

这样做没有意义因为世界上的每个开发团队在合并拉取请求之前都有一个已知的先决条件列表。这些要求几乎总是相同的，而且这些要求也是如此：

• 是否通过测试？
• 文档是否更新了？
• 这是否遵循我们的代码风格指南？
• 是否有若干位开发人员对此进行审查？

随着此列表变长，合并过程变得更容易出错。 “糟糕，在没有足够的开发人员审查补丁时 John 就点了合并按钮。” 要发出警报么？

在我的团队中，我们就像外面的每一支队伍。我们知道我们将一些代码合并到我们仓库的标准是什么。这就是为什么我们建立一个持续集成系统，每次有人创建一个拉取请求时运行我们的测试。我们还要求代码在获得批准之前由团队的 2 名成员进行审查。

当这些条件全部设定好时，我希望代码被合并。

而不用点击一个按钮。

这正是启动 Mergify 的原因。

Mergify 是一个为你按下合并按钮的服务。你可以在仓库的 .mergify.yml 中定义规则，当规则满足时，Mergify 将合并该请求。

无需按任何按钮。

随机抽取一个请求，就像这样：

这来自一个小型项目，没有很多持续集成服务，只有 Travis。在这个拉取请求中，一切都是绿色的：其中一个所有者审查了代码，并且测试通过。因此，该代码应该被合并：但是它还在那里挂起这，等待某人有一天按下合并按钮。

使用 Mergify 后，你只需将 .mergify.yml 放在仓库的根目录即可：

rules:
  default:
    protection:
      required_status_checks:
        contexts:
          - continuous-integration/travis-ci
      required_pull_request_reviews:
        required_approving_review_count: 1

通过这样的配置，Mergify 可以实现所需的限制，即 Travis 通过，并且至少有一个项目成员审阅了代码。只要这些条件是肯定的，拉取请求就会自动合并。

我们将 Mergify 构建为 一个对开源项目免费的服务。提供服务的引擎也是开源的。

现在去尝试它，不要让这些拉取请求再挂起哪怕一秒钟。合并它们！

如果你有任何问题，请随时在下面向我们提问或写下评论！并且敬请期待 - 因为 Mergify 还提供了其他一些我迫不及待想要介绍的功能！

via: https://julien.danjou.info/stop-merging-your-pull-request-manually/

作者：Julien Danjou 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

通过使用 GitHub 的 拉取请求 Pull Request 正确地进行代码审核，把时间更多的花在构建上，而在修复上少用点时间。

如果你不是每天编写代码，你可能不知道软件开发人员日常面临的一些问题。

• 代码中的安全漏洞
• 导致应用程序崩溃的代码
• 被称作 “技术债务” 和之后需要重写的代码
• 在某处你所不知道地方的代码已经被重写

代码审查 Code review 可以允许其他的人或工具来检查代码，帮助我们改善所编写的软件。这种审查（也称为 同行评审 peer review ）能够通过自动化代码分析或者测试覆盖工具来进行，是软件开发过程中两个重要的部分，它能够节省数小时的手工工作。同行评审是开发人员审查彼此工作的一个过程。在软件开发的过程中，速度和紧迫性是两个经常提及的问题。如果你没有尽快的发布，你的竞争对手可能会率先发布新功能。如果你不能够经常发布新的版本，你的用户可能会怀疑您是否仍然关心改进你的应用程序。

权衡时间：代码审查与缺陷修复

如果有人能够以最小争议的方式汇集多种类型的代码审查，那么随着时间的推移，该软件的质量将会得到改善。如果认为引入新的工具或流程最先导致的不是延迟，那未免太天真了。但是代价更高昂的是：修复生产环境中的错误花费的时间，或者在放到生产环境之前改进软件所花费的时间。即使新工具延迟了新功能的发布和得到客户欣赏的时间，但随着软件开发人员提高自己的技能，该延迟会缩短，软件开发周期将会回升到以前的水平，而同时缺陷将会减少。

通过代码审查实现提升代码质量目标的关键之一就是使用一个足够灵活的平台，允许软件开发人员快速编写代码，置入他们熟悉的工具，并对彼此进行同行评审。 GitHub 就是这样的平台的一个很好的例子。然而，只是把你的代码放在 GitHub 上并不会魔术般地使代码审查发生；你必须使用 拉取请求 Pull Request 来开始这个美妙的旅程。

拉取请求：关于代码的现场讨论

拉取请求 Pull Request 是 Github 上的一个工具，允许软件开发人员讨论并提出对项目的主要代码库的更改，这些更改稍后可以部署给所有用户看到。这个功能创建于 2008 年 2 月，其目的是在接受（合并）之前，对某人的建议进行更改，然后在部署到生产环境中，供最终用户看到这种变化。

拉取请求开始是以一种松散的方式让你为某人的项目提供更改，但是它们已经演变成：

• 关于你想要合并的代码的现场讨论
• 提升了所更改内容的可视功能
• 整合了你最喜爱的工具
• 作为受保护的分支工作流程的一部分可能需要显式的拉取请求评审

对于代码：URL 是永久的

看看上述的前两个点，拉取请求促成了一个正在进行的代码讨论，使代码变更可以更醒目，并且使您很容易在审查的过程中找到所需的代码。无论是对于新人还是有经验的开发人员，能够回顾以前的讨论，了解一个功能为什么以这种方式开发出来，或者与另一个相关功能的讨论相联系起来是无价的。当跨多个项目协调，并使每个人尽可能接近代码时，前后讨论的内容也非常重要。如果这些功能仍在开发中，重要的是能够看到上次审查以来更改了哪些内容。毕竟，审查小的更改要比大的容易得多，但不可能全都是小功能。因此，重要的是能够找到你上次审查，并只看到从那时以来的变化。

集成工具：软件开发人员的偏执

再看下上述第三点，GitHub 上的拉取请求有很多功能，但开发人员总是偏好第三方工具。代码质量是个完整的代码审查领域，它涉及到其它组件的代码评审，而这些评审不一定是由人完成的。检测“低效”或缓慢的代码、具有潜在安全漏洞或不符合公司标准的代码是留给自动化工具的任务。类似 SonarQube 和 Code Climatecan 这样工具可以分析你的代码，而像 Codecov 和 Coveralls 的这样工具可以告诉你刚刚写的新代码还没有得到很好的测试。这些工具最令人称奇的是，它们可以集成到 GitHub 中，并把它们的发现汇报到拉取请求当中！这意味着该过程中不仅是人们在审查代码，而且工具也在会在那里报告情况。这样每个人都可以完全了解一个功能是如何开发的。

最后，根据您的团队的偏好，您可以利用受保护的分支工作流的 必需状态 required status 功能来要求进行工具审查和同行评审。

虽然您可能只是刚刚开始您的软件开发之旅，或者是一位希望知道项目正在做什么的业务利益相关者，抑或是一位想要确保项目的及时性和质量的项目经理，你都可以通过设置批准流程来参与到拉取请求中，并考虑集成更多的工具以确保质量，这在任何级别的软件开发中都很重要。

无论是为您的个人网站，贵公司的在线商店，还是想用最新的组合以获得最大的收获，编写好的软件都需要进行良好的代码审查。良好的代码审查涉及到正确的工具和平台。要了解有关 GitHub 和软件开发过程的更多信息，请参阅 O'Reilly 的 《GitHub 简介》 一书， 您可以在其中了解创建项目、启动拉取请求以及概要了解团队的软件开发流程。

作者简介：

Brent Beer

Brent Beer 通过大学的课程、对开源项目的贡献，以及担任专业网站开发人员使用 Git 和 GitHub 已经超过五年了。在担任 GitHub 上的培训师时，他也成为 O’Reilly 的 《GitHub 简介》的出版作者。他在阿姆斯特丹担任 GitHub 的解决方案工程师，帮助 Git 和 GitHub 向世界各地的开发人员提供服务。

Peter Bell

Peter Bell 是 Ronin 实验室的创始人以及 CTO。培训是存在问题的，我们通过技术提升培训来改进它！他是一位有经验的企业家、技术专家、敏捷教练和 CTO，专门从事 EdTech 项目。他为 O'Reilly 撰写了 《GitHub 简介》，为代码学校创建了“精通 GitHub ”课程，为 Pearson 创建了“ Git 和 GitHub 现场课”课程。他经常在国际和国际会议上发表 ruby、 nodejs、NoSQL（尤其是 MongoDB 和 neo4j ）、云计算、软件工艺、java、groovy、j 等的演讲。

via: https://www.oreilly.com/ideas/how-to-use-pull-requests-to-improve-your-code-reviews

作者：Brent Beer, Peter Bell 译者：MonkeyDEcho 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出