gil*_*ly3 667
GitLab的"合并请求"功能相当于GitHub的"拉取请求"功能.两者都是将更改从另一个分支或分支拉入分支并将更改与现有代码合并的方法.它们是代码审查和变更管理的有用工具.
合并或拉取请求在git管理应用程序中创建,并要求指定人员合并两个分支.GitHub和Bitbucket等工具选择名称拉取请求,因为第一个手动操作是拉动功能分支.诸如GitLab和Gitorious之类的工具选择名称合并请求,因为这是受让人请求的最终操作.在本文中,我们将它们称为合并请求.
不应将"合并请求"与git merge命令混淆.也不应该将"拉取请求"与git pull命令混淆.两个git命令都在拉取请求和合并请求的幕后使用,但合并/拉取请求指的是比这两个命令更广泛的主题.
- MR到处都是更好的名字。直到我阅读了您对它的第一个操作的解释，而我理解了“合并请求”的含义才是对我的第一次理解，“拉取请求”对我而言就再没有意义了。“您好，能否请您将此代码合并到master分支中？” 与“您好，您能否将这段代码拉到<implied merging>的不可见分支”中？这里有一个明显的赢家。 (22认同)
- 我错过了什么？pull = fetch + merge.如果最终操作是合并,则必须获取第一个操作. (10认同)
- 我认为“拉取请求”来自这样的观点：您要求拥有您目标分支的任何人“拉入”您对您一直在处理的分支所做的任何提交。我怀疑这些术语的字面意思是来自命令的名称，而不是底层的概念。我认为“拉”术语对 git 的工作原理有更好的理解就更有意义，而“合并”的想法对于没有任何 git 背景的人来说更直观。每个人都知道，至少从直觉上来说，“合并”应该意味着什么，但拉和推是行话。 (7认同)
- @Granitosaurus同意。作为git的初学者，pull请求绝对不是我期望的。当我开始使用Gitlab时，合并请求立即就有意义了。 (3认同)
- 即使我同意你们所说的一切，“拉取请求”听起来更好 (3认同)
- 发出拉取请求时，GitHub 是否会创建中间/临时分支（不可见）？ (2认同)
rne*_*ves 51
它们是相同的功能
合并或拉取请求在git管理应用程序中创建,并要求指定人员合并两个分支.GitHub和Bitbucket等工具选择名称拉取请求,因为第一个手动操作是拉动功能分支.诸如GitLab和Gitorious之类的工具选择名称合并请求,因为这是受让人请求的最终操作.在本文中,我们将它们称为合并请求.
- 是的,但仍然有一个快速合并,必须在此之后完成,以获得代码.实际上,我认为在一个全职开发团队中,如果该功能的开发人员也合并,那么他们可能最好等待某人先审查他们的PR. (2认同)
icl*_*man 10
在冲突管理方面存在细微差别。如果发生冲突，Github 中的拉取请求将导致目标分支上的合并提交。在 Gitlab 中，当发现冲突时，所做的修改将在源分支上进行合并提交。
见https://docs.gitlab.com/ee/user/project/merge_requests/resolve_conflicts.html
“GitLab 通过在源分支中创建一个不会自动合并到目标分支的合并提交来解决冲突。这允许在合并更改之前审查和测试合并提交，防止意外的更改进入目标分支而无需审查或破坏建造。”
- 自我上一篇文章以来，情况发生了一些变化。我注意到，在 Github Enterprise 2.21.6 中（这可能在早期版本中发生了变化），如果发生冲突，现在的行为如下：创建合并分支提交，并将源分支移动到该提交。然后，当 PR 得到解决后，将创建合并拉取请求提交。目标分支将移动到合并拉取请求提交。合并分支提交和合并拉取请求提交具有不同的 SHA1。但是，如果两次提交之间没有进行任何更改，它们可能不包含任何差异。 (2认同)
在我看来，它们意味着相同的活动，但是从不同的角度来看：
考虑一下，爱丽丝对存储库A进行了一些提交，这是从鲍勃的存储库B派生的。
当爱丽丝想将她的更改“合并”到B时，她实际上希望鲍勃从“拉”这些更改。
因此，从爱丽丝的角度来看，这是一个“合并请求”，而鲍勃则将其视为“拉动请求”。
- 我不在乎鲍勃在做什么。我正在将我的代码合并到主分支，因此这是一个合并请求。据我所知，鲍勃可能已经死了，所以为什么我会认为这是一个拉取请求，这超出了我的范围。 (8认同)
GitLab 12.1（2019 年 7 月）引入了一个差异：
在讨论、规划和解决安全漏洞等机密问题时，由于 Git 存储库是公开的，因此开源项目保持高效尤其具有挑战性。
从 12.1 开始，现在可以使用“创建机密合并请求”按钮在简化的工作流程中解决公共项目中的机密问题，这有助于您在项目的私有分支中创建合并请求。
请参阅问题 58583中的“机密问题”。
GitHub 中也存在类似的功能，但涉及创建一个特殊的私有分支，称为“维护者安全咨询”。
GitLab 13.5（2020 年 10 月）将添加审阅者，该功能 之前已在 GitHub 上提供。