与将分支分支合并到另一个分支相比，请求请求的优势

Question

引发拉取请求然后合并而不是将分支拉到本地并合并到目标分支是否有任何优势？这属于一个小型工作团队。

Answer 1

是的，拉取请求给您的工作流程增加了一些复杂性。如果它是一个私有存储库，并且只有2-3个小型小组工作，则不需要它。

但另一方面，它有很多优点。

• 它允许讨论产品功能
• 在合并到主（主）分支之前，它有助于检查代码。
• 强制执行代码样式/构建/测试/ CI / CD和其他策略。

您可以在github文档中找到有关PR优势的更多详细信息 https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests

Answer 2

尽管最终结果将是相同的，但我确实认为使用PR +合并而不是拉取然后在推送到远程之前在本地合并之间存在一些差异。

从开发的角度来看，我们正在创建PR，是因为我们希望其他人查看我们的代码，对其进行测试，使用bug进行查找，对其进行样式设置以及对所有不正确的内容进行评论它。这样，我们可以确保所编写的代码正确无误，并且不会引起老板的凌晨3点打来的电话。 Git本身没有PR的概念，因此我们使用GitHub / GitLab / Bitbucket之类的东西来管理PR，并使代码审查更加容易。简单地说，我的意思是所有人都在同时查看同一代码，并且可以查看和讨论特定PR上的所有注释。

现在，除此之外，我们用于查看PR的不同系统之间存在一些细微差异。我不知道你们在使用什么，但是几乎所有不同的托管平台都可以让您快速操纵PR：

1. 合并
2. 调整基准
3. 合并后删除源分支
4. 编辑邮件

它们本身似乎很小，但是如果您必须手动合并一个分支，然后删除源分支，然后将其推送到远程，或者如果您必须手动重新设置基础然后合并它...这很麻烦。只需单击一个或两个按钮并完成它，比自己处理所有这些事情要快（同样，这取决于您使用的系统）。

我相信，即使对于一个小型团队，拥有PR的系统也将是有益的，但是您必须自己决定，什么才是最佳的，而最佳仅对您的男人有用。