在主服务器上启动请求请求或执行本地合并提交是否更好？

我使用GitHub已经有一段时间了，通常我会先推送功能分支，然后启动我自己合并的Pull Request。我发现它帮助我跟踪合并分支的位置。

但是最近我越来越多地阅读了有关Git的工作原理，我意识到我可以在合并分支时使用merge-commits进行引用。

因此，将功能分支合并到master中时，我该怎么办：在master上
执行merge-commit，然后将其推送到上游，或者在本地分支中推送并启动Pull Request？

我已经阅读了两人团队的请求介绍-合并我自己的请求吗？并且请告诉我工作，2人流量大的一个项目和我应该开拉请求从一个分支官方回购或我的叉子？但他们似乎都无法回答我的要求。

git-merge机制：在master上
使用git merge featurewhile会将分支合并feature到git历史记录中，并在git历史记录中master产生一个merge-commit（如果分支不能快速转发）。要强制执行merge-commit，请在中使用--no-ff选项merge。

合并请求请求机制：
当我们在GitHub上启动请求请求时，它会创建一个供GitHub Issue人们在合并之前在PR中进行讨论并讨论提交的地方。当PR在GitHub上合并时，它的作用与完全相同git merge feature。

我该怎么办？
因此，就历史而言，两者之间没有区别。
就贡献而言，在两种情况下，您的贡献者将没有任何不同。它们是相同的（减去漂亮的小聊天）。

最佳实践：
我无法找到最佳实践，但是逻辑表明，如果存储库中只有一个人，则PR并没有太大帮助。

@lxrec和@amon帮助我得出了这个结论。

正如Ashhar所说，从技术和历史角度看，两者没有区别。对于团队规模较小的项目，我更喜欢直接合并，而不是额外的创建PR的步骤。但是，当一项功能需要审阅/反馈时，或者当它是WIP时，将有多个人在使用该功能，我倾向于打开PR，并在PR的描述中添加任务列表。

请注意，git merge如果没有对master进行任何更改，则可能会使用快进，因此您可能要使用git merge --no-ff。我倾向于不这样做。

因此，总而言之，仅在需要讨论时才使用PR。否则，直接合并即可。