交付 / 展示 / 询问
现代分支策略
交付/展示/询问是一种分支策略，它结合了拉取请求的功能和持续交付变更的能力。变更被分类为交付（无需审查即可合并到主线）、展示（打开拉取请求以供审查，但立即合并到主线）或询问（在合并之前打开拉取请求以供讨论）。
2021 年 9 月 8 日
Rouan 是一位软件工程师和技术负责人，他帮助构建优秀的团队和高质量的软件。他曾在金融服务、教育、休闲和能源行业的公司使用过各种技术栈（包括担任 Thoughtworks 的顾问）。他关心保持简单、建立包容性团队以及写下他所学到的东西。
如何使用拉取请求进行持续集成？
许多软件团队广泛采用拉取请求。有些人喜欢它们，有些人则怀念持续集成的时代——那时你从不创建分支，你的团队一直都在整合他们的变更。
在某些方面，拉取请求改变了游戏规则。代码托管工具提供了出色的代码审查功能。有许多 SaaS 提供商提供可在您的拉取请求上运行的服务——从运行测试和检查代码质量到部署完整的预览环境。
但是，采用拉取请求作为贡献代码的主要方式也带来了一些问题。我们已经失去了一些在进行持续集成时所拥有的“准备交付”的心态。正在进行的功能通过延迟集成来避免阻碍，因此我们陷入了持续集成试图解决的低频集成的陷阱。
有时拉取请求会搁置并变得过时，或者在我们等待审查时不确定要做什么。有时，当我们想“好吧，反正我在这里，不妨把这个也做了”时，它们就会变得臃肿。
我们也厌倦了要审查的拉取请求的数量，所以我们不再讨论代码了。我们不再关注，只是点击“批准”或说“看起来不错”。
介绍 交付 / 展示 / 询问
我与我的团队一起使用了一种软件分支方法。它运行得非常好，所以我想与你分享。
每次进行更改时，你都可以选择以下三个选项之一：交付、展示或询问。
交付
图 1：更改直接进入主线
这感觉最像持续集成。你想进行更改，所以你直接在你的主线上进行更改。当你这样做时，你不需要等待任何人将你的更改投入生产。你不需要请求代码审查。无需大惊小怪——只需进行更改，并使用所有常见的持续集成技术来确保安全。
在以下情况下效果很好
- 我使用已建立的模式添加了一个功能
- 我修复了一个不起眼的错误
- 我更新了文档
- 我根据你的反馈改进了我的代码
展示
图 2：打开 PR 以获取反馈，但立即合并
这就是我们采用持续集成思维方式并仍然利用拉取请求可以提供的所有好处的地方。你在分支上进行更改，打开拉取请求，然后合并它，而无需等待任何人。你需要等待你的自动化检查（测试、代码覆盖率、预览环境等），但你不需要等待任何人的反馈就可以继续进行更改。
通过这样做，你已经快速地将你的更改上线，同时仍然为反馈和对话创造了空间。你的团队应该会收到你的拉取请求的通知，然后他们可以审查你所做的工作。他们可以就你的方法或代码向你提供反馈。他们可以问你问题。他们可以从你所做的事情中学习。
在以下情况下效果很好
- 我希望你能就如何改进这段代码提供反馈
- 看看我使用的新方法或模式
- 我重构了 X，所以现在它看起来像这样
- 真是个有趣的错误！看看我是怎么修复的。
询问
图 3：打开 PR 以获取反馈并在合并之前等待
在这里我们暂停一下。我们在分支上进行更改，打开拉取请求，并在合并之前等待反馈。也许我们不确定我们是否采取了正确的方法。也许有些代码我们不太满意，但不确定如何改进它。也许你做了一个实验，想看看人们的想法。
现代代码审查工具为这种对话提供了一个很好的空间，你甚至可以召集整个团队来查看拉取请求并进行讨论。
在以下情况下效果很好
- 这行得通吗？
- 我们对这种新方法有什么看法？
- 我需要帮助来改进它
- 我今天做完了，明天合并
规则
对话
虽然拉取请求是讨论更改的有用方式，但它们也有一些缺陷。最诱人的反模式是它们可以取代其他进行对话的方式。
分支的一个常见问题是，人们在没有讨论的情况下就决定了一种方法。到打开拉取请求时，已经在可能并非最佳的解决方案上投入了时间。审查人员会受到所选解决方案的影响，并且发现很难提出其他方法。变更集越大，分支存在的时间越长，这个问题就越严重。在开始之前与你的团队交谈，这样你就可以获得更好的想法并避免返工。
请记住，拉取请求并不是展示或询问的唯一方式。打电话或走到某人的办公桌前。尽早并经常展示你的工作。尽早并经常寻求帮助和反馈。一起完成任务。
没有打开拉取请求也不是避免讨论代码的理由。重要的是，你的团队仍然要有一个良好的反馈文化，并就你的想法和学习内容相互交流。
平衡
现在有三个选项——我应该更经常地选择哪一个？
这要看情况。我认为每个团队在任何给定时间都会有自己的平衡。
当你以既定的模式交付功能时，你将进行更多“交付”。当你的团队中有高度的信任，并且人们都拥有相同的质量标准时，你也会进行更多“交付”。
但是，如果你仍然在相互了解，或者你们都在做一些新的事情，那么就需要更多的对话，所以你会做更多“展示”和“询问”。初级工程师可能经常“展示”和“询问”。高级工程师可能会“交付”很多，但偶尔会“展示”一种新技术或每个人都应该尝试的重构。
有些团队没有太多灵活性。某些行业受到高度监管，每次更改都需要经过批准或审查流程。有很多方法可以实现这一点——无论你是否分支——我在这里就不赘述了。
我的团队应该采用这种方法吗？
你已经这样做了。
想想你的团队是如何工作的，你就会注意到你在做一些交付/展示/询问的平衡。我见过的大多数团队都属于以下两种情况之一：“主要交付”或“主要询问”。
如果你主要进行交付
如果你很少分支，并且所有提交都直接进入主线，那么你就是“主要交付”。如果你是这样，请考虑一下做一些“展示”是否对你有帮助。
拉取请求模型如此受欢迎的一个重要原因是，它们支持远程优先和异步团队。明确地向他人“展示”你工作中有趣的部分可以帮助他们学习并让他们感到自己参与了对话，尤其是在他们远程工作或工作时间不同步的情况下。
我还发现（尤其是在那些谈论得不够多的团队中[1]），总是提交到主线可能意味着只有在问题出现几周后才会注意到。到那时，就很难对它们进行有用的讨论，因为细节已经模糊不清。鼓励团队成员使用“展示”方法意味着你可以在进行过程中就代码进行更多对话。
如果你主要进行询问
如果你的团队正在为大多数更改打开拉取请求，那么你就是“主要询问”。虽然拉取请求是质量和反馈的有用工具，但它们存在扩展问题。等待批准不可避免地需要时间。如果有太多更改在排队等待反馈，那么要么反馈的质量会下降，要么进度会变慢。尝试更多地“展示”，这样你就可以两全其美。
你依赖于大量“询问”的原因可能是你存在信任问题。“所有更改都必须获得批准”或“每个拉取请求都需要 2 名审查人员”是常见的策略，但这表明对开发团队缺乏信任。
这是有问题的，因为批准步骤只是一种权宜之计——它不会解决你潜在的信任问题。多做一些“展示”，这样你就可以减轻开发管道中的压力。然后将你的精力集中在建立信任的活动上，例如培训、团队讨论或合奏编程。每次开发人员“展示”而不是“询问”都是他们与团队建立信任的机会。
你依赖于大量“询问”的另一个原因可能是，你没有安全的方法将更改放到主线上。在这种情况下，你需要学习和实施保持主线可发布的技术。与此同时，更多地“展示”可以成为减少将安全更改投入生产的障碍的一种方式。减少障碍也将成为对团队成员的一种激励——如果你能找到一种方法使你的更改安全，它就可以更快地上线。
结论
那么什么是交付/展示/询问？从根本上说，它是两件事
首先——一个帮助你两全其美的技巧——合并你自己的拉取请求，而无需等待反馈，然后在反馈到来时注意反馈。
其次——一种更具包容性和动态性的分支策略视图。交付/展示/询问提醒我们，每个团队的方法都位于“始终交付”和“始终询问”之间的某个连续体上。它鼓励我们独立思考每一次更改，并问问自己——我应该交付、展示还是询问？
致谢
感谢那些对早期草案提供详细反馈的人：Martin Fowler、Brian Guthrie、Federico Blancato、Stephen Cresswell 和 Paul Hammant。
还要感谢 Matthew Harward、Kief Morris、Giuseppe Pereira、Marcos Vinícius da Silva、Birgitta Böckeler、Prashanth R、Premanand Chandrasekaran、Joao Paulo Moraes 和 Mark Taylor，他们在 ThoughtWorks 内部邮件列表上讨论了这篇文章的草案。
脚注
1: 结对编程是一种鼓励团队持续沟通的有效技术
重大修订
2021 年 9 月 8 日：发布