Pull Request 与持续集成：如何平衡代码审查和快速交付？

Pull Request 已经被许多软件团队广泛采用。有人非常喜欢这种协作方式，也有人怀念更接近持续集成初衷的开发模式——那时，开发者不需要频繁创建长期分支，团队成员会持续把各自的变更合并到主干。

从很多方面看，Pull Request 的确改变了软件开发方式。现代代码托管平台提供了强大的代码审查能力，许多 SaaS 服务也可以围绕 Pull Request 自动执行各种任务，包括运行测试、检查代码质量，以及部署功能完整的预览环境。

但当团队把 Pull Request 作为主要的代码贡献方式时，也会产生一些新的问题。

团队可能逐渐失去持续集成所强调的“主干始终可发布”这一理念。正在开发中的功能因为迟迟没有集成，无法尽早产生价值，团队也会重新陷入低频集成的困境——而这恰恰是持续集成最初试图解决的问题。

有时，一个 Pull Request 会长时间无人处理，逐渐陷入停滞。提交者在等待代码审查时，也不知道是否应该继续推进其他工作。

有时，我们还会产生一种想法：“既然已经改到这里了，不如顺便把这个也做掉。”结果是 Pull Request 越来越大，越来越难以理解、审查和合并。

当待审查的 Pull Request 越积越多时，团队也容易出现审查疲劳。大家不再真正讨论代码，只是机械地点一下“批准”，或者留下一句“看起来没问题”。

那么，软件团队该如何兼顾 Pull Request 的代码审查优势与持续集成的快速交付能力？Ship / Show / Ask 提供了一种更灵活的答案。

Ship / Show / Ask：三种 Pull Request 协作方式

我曾和团队一起采用过一种简单的分支协作方法，效果非常不错，因此想把它分享出来。

对于每一次代码变更，你都可以选择以下三种方式之一：

• Ship：直接交付
• Show：先合并，再展示
• Ask：先询问，再合并

这三种方式的区别，不在于是否使用 Pull Request，而在于是否需要在合并前等待人工反馈。

Ship：直接交付到主干

Ship 最接近传统的持续集成和主干开发方式。

当你要进行一项改动时，可以直接在主干上完成，也可以使用一个生命周期极短的分支，并在完成后迅速合并。你不需要等待他人审查，也不需要请求批准。

整个过程非常直接：完成修改，并依靠成熟的持续集成实践保证变更安全。

这意味着团队必须具备足够完善的自动化测试、持续集成、监控和回滚能力，确保主干始终处于可发布状态。

Ship 通常适用于以下情况：

• 按照团队已有模式添加一个功能；
• 修复一个简单、低风险的缺陷；
• 更新文档；
• 根据已经获得的反馈改进代码；
• 完成范围明确、风险较低的常规变更。

这种方式强调的是：当变更足够清晰、安全，并且符合既有约定时，不要人为增加不必要的等待时间。

Show：合并 Pull Request 后再获取反馈

Show 是持续集成理念与 Pull Request 优势之间的一种平衡。

你在分支上完成修改，创建 Pull Request，然后在自动化检查通过后直接合并，而不必等待他人审查或批准。

你仍然需要等待测试、代码覆盖率检查、静态分析和预览环境等自动化结果，但不需要等团队成员给出反馈，才允许变更进入主干。

这样一来，你既可以快速交付变更，又能为团队保留反馈和代码讨论的空间。

团队成员会收到 Pull Request 通知，可以查看你的实现方式。他们可以提出改进建议、询问设计思路，也可以从你的工作中学习。

即使代码已经合并，这些反馈仍然有价值。如果有人提出了更好的建议，你依然可以在后续变更中继续改进。

Show 通常适用于以下情况：

• 希望团队对代码提出改进建议，但不希望因此阻塞交付；
• 想向团队展示一种新的实现方式或设计模式；
• 完成了一次值得分享的重构；
• 修复了一个有代表性或较有意思的缺陷；
• 希望其他成员了解某项变更，但不需要事先批准；
• 变更风险可控，但具有一定的学习和讨论价值。

Show 的核心是：

反馈可以异步发生，但交付不必因此等待。

Ask：代码审查后再合并 Pull Request

图 ：创建 Pull Reuest，等待反馈后再决定是否合并

Ask 意味着团队需要在合并前稍作停顿。

你在分支上完成修改，创建 Pull Request，然后等待反馈，再决定是否合并。

选择 Ask，往往是因为你对当前方案并不完全确定，或者确实需要团队共同作出判断。

可能的情况包括：

• 不确定当前方案是否正确；
• 对部分代码不满意，却不知道如何改进；
• 正在尝试一种实验性方案，希望听取其他人的意见；
• 变更风险较高，需要更多人共同评估；
• 变更涉及架构、接口或长期维护方式；
• 需要特定领域专家确认。

现代代码审查工具非常适合承载这类讨论。必要时，你甚至可以邀请整个团队一起查看 Pull Request，并围绕设计和实现展开同步讨论。

Ask 通常适用于以下表达：

• “这种方案可行吗？”
• “大家怎么看这种新的实现方式？”
• “我需要帮助改进这里。”
• “今天先做到这里，明天听完反馈后再合并。”
• “这项变更影响较大，希望大家一起确认。”

Ask 的重点不是流程审批，而是主动寻求帮助和共同判断。

使用 Ship / Show / Ask 的基本规则

为了让这套 Pull Request 分支策略真正发挥作用，团队需要遵循几项基本原则。

代码审查不应成为所有 Pull Request 的必要条件

不是每一次变更都需要等待正式批准。

如果所有 Pull Request 都必须经过审查才能合并，那么即使是低风险、常规性的修改，也会产生额外等待时间。

代码审查应该服务于质量、学习和风险管理，而不是机械地成为所有变更的必经关卡。

变更提交者应该能够自行合并 Pull Request

开发者应该能够决定自己的变更属于 Show 还是 Ask，并在自动化检查通过后控制合并时机。

如果每次合并都依赖他人操作，团队就很难真正实现快速集成。

当然，这种自主权必须建立在清晰的质量标准、良好的工程实践和足够的团队信任之上。

必须采用成熟的持续集成与持续交付实践

无论采用 Ship、Show 还是 Ask，主干都必须始终保持可发布状态。

这需要团队具备一系列 CI/CD 能力，例如：

• 自动化测试；
• 持续集成；
• 小批量变更；
• 功能开关；
• 渐进式发布；
• 自动化部署；
• 监控与告警；
• 快速回滚。

功能开关尤其重要，因为它允许团队将尚未完全开放的功能安全地合并到主干，同时控制功能何时、向哪些用户生效。

在实践中，团队也可以借助 PingCode 这类覆盖研发全生命周期的管理平台，将需求、开发任务、代码变更、测试结果、缺陷和版本发布关联起来，并接入代码托管、持续集成等研发工具。这样既能减少跨系统流转造成的信息断层，也有助于追踪 Pull Request 从开发到测试、发布的完整过程。

分支生命周期不应过长

分支存在的时间越长，与主干产生的偏差就越大，最终集成时发生冲突和意外问题的概率也越高。

因此，团队应该频繁同步主干上的最新变更，并尽快完成合并。

理想情况下，分支应该尽可能短命，单次代码变更也应该尽可能小。

Pull Request 不能替代团队沟通

Pull Request 是讨论代码变更的有效方式，但它并不能替代所有其他沟通方式。

一个常见的反模式是：团队认为只要创建了 Pull Request，就已经完成了沟通。

实际上，许多分支管理问题都源于团队在实现之前缺少讨论。

开发者可能在没有和任何人交流的情况下，独自决定采用某个方案。等到 Pull Request 创建时，已经在一个并非最优的方向上投入了大量时间。

此时，审查者很容易被现有实现限制住思路，更难提出完全不同的替代方案。

变更集越大、分支存在的时间越长，这个问题就越严重。

因此，在开始编码之前和团队沟通，往往能够获得更好的想法，并减少后续返工。

请记住，Pull Request 并不是展示工作或寻求帮助的唯一方式。

你可以发起一次通话，也可以直接和同事讨论。应尽早、频繁地展示工作进展，也应尽早、频繁地寻求帮助和反馈。

不要等到已经完成大量代码后，才第一次向团队展示自己的方案。

真正有效的协作，是共同完成工作，而不是独自完成后再等待他人评价。

同样，不创建 Pull Request 也不意味着可以回避代码讨论。

团队仍然需要建立良好的反馈文化，持续交流实现思路、设计决策和经验教训。

如何平衡 Ship、Show 和 Ask？

现在有三种选择，那么团队应该更多地使用哪一种？

答案取决于具体情况。

每个团队都会在 Ship、Show 和 Ask 之间形成自己的平衡，而且这种平衡还会随着团队成员、项目阶段和业务风险的变化而调整。

当团队按照已经成熟的模式交付功能时，通常会更多地采用 Ship。

当团队成员之间高度信任，并且大家对代码质量、安全性和工程标准有一致理解时，也会更多地采用 Ship。

但如果团队成员还在互相了解，或者大家正在探索新技术、新架构和新的工作方式，那么沟通就更加重要，此时通常会更多地采用 Show 和 Ask。

经验较少的工程师可能会更频繁地使用 Show 和 Ask，以便获得反馈、加速学习。

经验丰富的工程师可能会直接 Ship 大量常规变更，但在引入新技术、进行重要重构或尝试新模式时，也会主动选择 Show，让团队成员共同了解和学习。

有些团队的选择空间相对有限。

例如，某些受到严格监管的行业，可能要求所有变更必须经过正式审批或审计。即使如此，团队仍然可以通过不同的分支和集成策略满足合规要求，而不一定要让所有变更都长期停留在分支上。

团队是否应该采用 Ship / Show / Ask？

从某种意义上说，你的团队很可能已经在使用这套方法。

仔细观察团队当前的协作方式，你会发现，团队其实已经在“直接交付、展示反馈和请求审查”之间形成了某种平衡。

我见过的大多数团队，大致可以分为两种类型：

• 以 Ship 为主；
• 以 Ask 为主。

如果团队以 Ship 为主

如果团队很少创建分支，大多数提交都会迅速进入主干，那么你们就是“以 Ship 为主”的团队。

这种方式通常意味着团队集成频率高、交付速度快，也往往具备较强的工程信任。

但即便如此，你们仍然可以考虑是否需要增加一些 Show。

Pull Request 模型之所以流行，很大程度上是因为它非常适合远程优先和异步协作。

主动向其他成员展示工作中值得关注的部分，可以帮助他们学习、了解系统变化并参与讨论。对于远程办公、跨地区或工作时间不同的团队，这一点尤其重要。

我还发现，在沟通不足的团队中，如果所有代码都直接进入主干，一些值得讨论的变更可能要过几周才会被注意到。

到那时，相关细节已经变得模糊，很难再展开有效讨论。

鼓励团队成员采用 Show，可以让大家在代码刚刚完成、背景仍然清晰时，就围绕实现方式展开交流。

如果团队以 Ask 为主

如果团队几乎所有变更都需要创建 Pull Request，并等待他人批准，那么你们就是“以 Ask 为主”的团队。

Ask 的确可以帮助提高代码质量、收集反馈和控制风险，但它很难无限扩展。

等待批准必然会消耗时间。

当等待反馈的变更越来越多时，通常只会出现两种结果：

• 代码审查质量下降；
• 软件交付速度放慢。

因此，团队可以尝试增加 Show 的比例，以同时获得快速交付和异步反馈的好处。

过度依赖 Ask，可能意味着团队缺乏信任

“所有变更都必须获得批准”或“每个 Pull Request 都必须由两个人审查”，是很常见的团队策略。

但这些规则也可能表明，团队并不真正信任开发者能够独立作出安全、合理的变更。

这会带来问题，因为审批流程只是一种临时保护措施，无法从根本上解决信任不足。

团队可以尝试增加 Show 的比例，减轻开发流程中的等待压力。

与此同时，应把更多精力投入真正有助于建立信任的活动，例如：

• 技术培训；
• 团队设计讨论；
• 结对编程；
• 集体代码阅读；
• 明确工程标准；
• 改善测试与自动化能力。

每当开发者选择 Show 而不是 Ask，并成功交付安全变更时，都是一次积累团队信任的机会。

过度依赖 Ask，也可能意味着团队缺乏安全发布能力

另一个可能的原因是，团队没有足够安全的方法将变更合并到主干。

如果主干经常不可发布，测试覆盖不足，部署风险高，或者无法快速回滚，那么团队自然会依赖人工审查来降低风险。

但人工审批无法替代真正的持续集成和持续交付能力。

在这种情况下，团队需要学习并采用能够保证主干可发布性的实践，包括自动化测试、功能开关、渐进式发布和快速回滚等。

与此同时，可以先从低风险变更开始增加 Show，逐步降低安全变更进入生产环境的门槛。

更低的交付门槛也会激励开发者。只要团队能够找到可靠的方法保证变更安全，就可以更快地把价值交付给用户。

结论：Pull Request 与持续集成如何兼容？

那么，Ship / Show / Ask 究竟是什么？

从根本上说，它包含两个核心思想。

第一，它提供了一种同时获得持续集成和 Pull Request 优势的方法：

你可以在不等待人工反馈的情况下合并自己的 Pull Request，同时仍然保留代码反馈通道，并在收到建议后继续改进。

第二，它提供了一种更加灵活、更具包容性的分支策略视角。

Ship / Show / Ask 提醒我们，每个团队都处在“所有变更直接交付”和“所有变更等待审查”之间的某个位置。

它鼓励团队根据每一次变更的风险、复杂度和讨论价值，独立作出判断，而不是机械地对所有变更采用同一种 Pull Request 流程。

Pull Request 与持续集成并不冲突。真正的问题不在于是否创建 Pull Request，而在于是否把人工审批变成所有代码变更的默认前提。

面对下一次代码变更时，不妨问问自己：

这一次，我应该直接交付、先合并再展示，还是先询问再合并？