它们是相同的特征

合并或拉取请求是在git管理应用程序中创建的，并要求指定的人员合并两个分支。GitHub和Bitbucket等工具选择了拉请求的名称，因为第一个手动操作将是拉功能分支。像GitLab和Gitorious这样的工具选择名称合并请求，因为这是向受让人请求的最终操作。在本文中，我们将它们称为合并请求。 ——https://about.gitlab.com/2014/09/29/gitlab-flow/

正如在之前的回答中提到的，两者的目的几乎相同。就我个人而言，我喜欢git的rebase和merge request(就像在gitlab中一样)。它减轻了审阅者/维护者的负担，确保在添加合并请求时，特性分支包含了在特性分支创建后在主分支上完成的所有最新提交。这里有一篇非常有用的文章详细解释了rebase: https://git-scm.com/book/en/v2/Git-Branching-Rebasing

在我看来，它们意味着相同的活动，但从不同的角度:

想想看，Alice在存储库A上进行了一些提交，而存储库A是从Bob的存储库B派生出来的。

当Alice想要将她的更改“合并”到B中时，她实际上想要Bob从A中“拉出”这些更改。

因此，从Alice的角度来看，这是一个“合并请求”，而Bob将其视为一个“拉取请求”。

GitLab 12.1(2019年7月)引入了一个区别:

“机密问题的合并请求”

在讨论、计划和解决机密问题(如安全漏洞)时，由于Git存储库是公共的，开源项目要保持效率尤其具有挑战性。

从12.1开始，现在可以使用创建机密合并请求按钮在简化的工作流中解决公共项目中的机密问题，该按钮可以帮助您在项目的私有分支中创建合并请求。

参见58583期的“机密问题”。

GitHub中也有类似的功能，但涉及到创建一个特殊的私有分支，称为“维护者安全咨询”。

GitLab 13.5(2020年10月)将添加评审人员 之前已经在GitHub上可用。

在冲突管理方面有微妙的区别。在冲突的情况下，Github中的拉请求将导致在目标分支上的合并提交。在Gitlab中，当发现冲突时，所做的修改将在源分支的合并提交中进行。

参见https://docs.gitlab.com/ee/user/project/merge_requests/resolve_conflicts.html

“GitLab通过在源代码中创建合并提交来解决冲突 未自动合并到目标分支的分支。这 允许在更改之前检查和测试合并提交 合并，防止意外的更改进入目标分支 没有审查或破坏构建。”

它们是相同的特征

合并或拉取请求是在git管理应用程序中创建的，并要求指定的人员合并两个分支。GitHub和Bitbucket等工具选择了拉请求的名称，因为第一个手动操作将是拉功能分支。像GitLab和Gitorious这样的工具选择名称合并请求，因为这是向受让人请求的最终操作。在本文中，我们将它们称为合并请求。 ——https://about.gitlab.com/2014/09/29/gitlab-flow/