拉取请求作者必须合并的代码审查工作流

我公司的几个团队在实践一个我从未见过的代码审查工作流。我试图理解其背后的想法，并认为使整个公司保持一致具有价值。（我为多个代码库做出了贡献，过去的差异让我感到震惊。）

1. 代码作者提交请求请求
2. 审阅者检查代码
3. • 如果审阅者批准，他们会按照“看起来不错，随时可以合并”的方式发表评论
   • 如果审阅者有疑问，他们会留下诸如“请先解决X和Y的小问题，然后合并”之类的评论（有关重大更改，请返回步骤2）。
4. 代码作者在必要时进行更改，然后合并自己的请求请求

我有以下担忧：

• 在第3步获得批准的情况下，此工作流程将为拉取请求作者创建一个看似不必要的往返。已经在查看代码的审阅者可以立即将其合并。

• 在第3步请求更改的情况下，合并拉取请求的代理机构现在仅由PR的作者负责。除了作者之外，没有人会在合并之前查看这些更改。

此工作流程还有哪些其他优点或缺点？此工作流程在其他工程团队中是否常见？

在第一种情况下，通常是礼貌的。在大多数组织中，合并会启动一系列自动测试，如果测试失败，则必须立即进行处理。尤其是在提交请求和审查请求之间存在明显的延迟时，有礼貌地允许将其合并到作者的时间表中，因此他们有时间处理任何意外的后果。最简单的方法是让他们自己合并。

另外，有时作者会在以后意识到不应该合并请求请求的原因。也许其他开发人员的PR拥有更高的优先权，并且会引起冲突。也许她想到了一个未发现的用例。审查评论可能引发了集体讨论，需要进一步调查才能完全解决问题。作者对代码最了解，因此有必要为他或她提供关于何时合并的最后决定。

第二点，那只是信任的问题。如果您不信任别人而不经过反复检查就能解决小问题，那么他们就不应该为您工作。如果问题足够大，需要在修复后再次进行检查，请信任审阅者。

话虽如此，我偶尔会合并其他作者的拉取请求，但这通常是非常简单的更改，也可能是来自外部来源的更改，我个人负责应对任何测试自动化故障。

在小团队中，我倾向于将最初的作者合并他们自己的请求，这是我的首选工作流程。除了已经提到的技术优势（例如在解决合并冲突方面）之外，我认为它在文化层面上也增加了价值：它建立了主人翁感。

我为（罕见）情况指定了最初的作者，当时另一位开发人员会将提交添加到打开的请求中（拉动进行中的功能分支并将其推回去）。这并不经常发生，而且会导致通话亲自或通过懈怠：这些额外的提交（别人）应该不会感到意外降落在那里！在这种情况下，最初的作者是指提交拉取请求的人。

在我的组织中，我们在请求请求方面很陌生，而您的问题是我一直在思考的问题。

我想补充一点：在某些工具（我们使用TFS）中，可能存在与拉取请求关联的工作项。

如果是这种情况，跟踪审阅者何时执行合并将变得有些麻烦。在那种情况下，开发人员必须重新访问PR，打开错误或更改请求并将其标记为“已解决”。如果我们将其标记为“已解决”为时过早，则测试人员认为该修补程序已经是当前版本的一部分。

TFS 2017改进了对拉取请求的实施。现在，如果满足所有条件（无合并冲突，审阅者批准且构建没有中断），开发人员可以请求“合并请求”自动合并。YMMV。

这样，作者就有机会改变对分支的看法，也许他想出了应该以其他方式完成的工作，并将额外的费用重新考虑。