为什么使用拉取请求而不是合并

使用拉取请求而不是简单地将分支合并到没有分支的master中有什么好处？特别是在所有开发人员都拥有完全掌握母版权限的团队中。

拉取请求提供了制衡功能，即使任何人都可以推送到主服务器。

最大的优点是它们为代码审查提供了机会。负责执行拉取的人员可以查看代码和测试，并确保它们符合组织或团队的任何准则。代码审查还有其他原因 -培训，发现缺陷或增强功能，对系统上的团队进行交叉培训，为测试人员提供系统的白盒视图。

如果执行拉动的人员熟悉系统的体系结构，则他们可以确保所做的更改符合系统的体系结构构想，尤其是在整个团队可能没有长期构想的情况下。

如果您将来决定整个团队不应该拥有主人权限，养成使用拉取请求的习惯也可能会对您的团队有所帮助。如果您的团队不断壮大，尤其是如果您的团队成员是刚接触该产品和/或刚接触Git的成员，那么不让他们访问master可以更安全地保证产品完整性。

完成功能分支和派生+拉取请求后，我认为当你们都在同一个团队或公司中发展时，拉取请求几乎没有优势

它们确实提供了用于代码审查的良好机制和界面，但也使整个“完成工作”的过程变得复杂和缓慢。特别是如果您有许多小功能，每个小功能都在等待审阅，合并，然后将所有其他功能再次与master合并以进行更改等。如果您有大功能，则这些功能将变得难以审阅，因此您将陷入困境。

话虽如此，您可以在同一仓库中的分支之间进行拉取请求。您不必分叉或具有不同的权限。

此外，您还必须考虑整个方法和工作流程。您是否还有票务系统，CI，自动验收测试等？您的代码审查是否在代码上线之前提供了至关重要的单项检查，还是仅仅是橡皮图章练习（这些工作被工作流程中的其他检查所多余）？

有一个称为康威定律的观察，其中指出：

设计系统的组织被限制产生设计，这些设计是这些组织的通信结构的副本。

这与拉取请求有什么关系？拉取请求是代码关键连接处的主要沟通渠道。在代码进入测试和生产的下一个阶段之前，它们为审查，自动测试和改进提供了机会，在这些阶段中，这些更改更难撤回，并且浪费了很多人更多的时间。

同样，康韦定律建议，如果您希望拥有一个微服务架构，该架构具有完全独立的自治责任区和定义明确的界面，那么您组织的通信渠道应反映您希望实现的架构。这意味着由5至10人组成的小型团队应该可以直接提交对任何给定微服务的访问权限，并且应该要求该团队之外的任何人都要进行拉取请求。这样可以确保最熟悉微服务的人员可以对其进行审查和提出建议。

如果您拥有一个大型组织，每个人都可以直接访问任何地方，那么阻力最小的通信渠道将使您陷入泥潭。

拉取请求仅在您不付出任何代价时才感到负担。我曾在一个星期内无法完成任何工作的环境中工作，因为构建始终被破坏，而我曾在有人提交了拉取请求并且我什至不必对其进行审查的环境中工作，因为它们被破坏了CI的构建，我告诉您，它们值得每一秒钟的努力。

卡尔·比勒费尔德（Karl Bielefeldt）完全正确。我要补充：这一切都与质量有关。

许多（大多数？）商店没有正式的流程来管理开发，结果是：“我在一个工作环境中工作了一个星期，因为构建总是坏了，所以我一直在工作在有人提交请求的环境中，我什至不必审查它，因为他们破坏了CI的构建，我告诉你，他们值得每一分的努力。”

确实值得付出努力。

我们使用请求请求进行代码审查-无需通过请求就不得将任何代码合并到主开发分支中（在我们的情况下通常为“ develop”，在某些情况下为“ master”）。我们不会使用存储库控件来强制执行此操作，但这是因为我们不必这样做-我们的开发人员已经足够成熟，不会滥用该过程。