587

What is the difference between a Pull request and a Merge request?

In GitHub, it's a Pull Request while in GitLab, for example, it's a Merge Request. So, is there a difference between both of these?

Milan
  • 489
  • 4
  • 13
Pacane
  • 16,528
  • 15
  • 52
  • 88

6 Answers6

923

GitLab's "merge request" feature is equivalent to GitHub's "pull request" feature. Both are means of pulling changes from another branch or fork into your branch and merging the changes with your existing code. They are useful tools for code review and change management.

An article from GitLab discusses the differences in naming the feature:

Merge or pull requests are created in a git management application and ask an assigned person to merge two branches. Tools such as GitHub and Bitbucket choose the name pull request since the first manual action would be to pull the feature branch. Tools such as GitLab and Gitorious choose the name merge request since that is the final action that is requested of the assignee. In this article we'll refer to them as merge requests.

A "merge request" should not be confused with the git merge command. Neither should a "pull request" be confused with the git pull command. Both git commands are used behind the scenes in both pull requests and merge requests, but a merge/pull request refers to a much broader topic than just these two commands.

gilly3
  • 78,870
  • 23
  • 132
  • 169
  • 2
    Does GitHub create an intermediate/temporary branch (invisible) when a pull request is made? – Robert Koritnik Nov 26 '15 at 14:16
  • 1
    @stevemao can we access them? Are they really read only as we can resolve conflicts on them? – Robert Koritnik Dec 27 '15 at 09:41
  • 1
    Of course you can access them. You can resolve them on your own branch. – stevemao Dec 27 '15 at 09:43
  • 17
    What am I missing? pull = fetch + merge. If the final action is merge, then the first action must be fetch. – Vytenis Bivainis Jul 21 '17 at 23:07
  • 1
    @VytenisBivainis I think the merge here refers to the last merge command in the following pseudo code: `git checkout feature-branch && ./test_and_review_the_branch && git checkout master && git merge feature-branch` – Per Lundberg Sep 04 '18 at 06:48
  • 128
    MR is just better name all around. Pull Request never made sense to me untill I read your explanation of it being first action, while I understood what Merge Request means the second I read it for the first time. "hello, could you please Merge this code to master branch?" vs "hello, could you pull this code to invisible branch for " - there's a clear winner here. – Granitosaurus Feb 18 '19 at 09:17
  • 19
    @Granitosaurus Agreed. As a beginner to git, pull requests were absolutely not what I expected them to be. When I started using Gitlab, merge requests made sense right away. – Mark Lyons Apr 19 '19 at 14:32
  • "Back in the day", we used to call all this a "branch request", or "request to create a branch". I find merge ambiguous, since it's only defined for a specific destination branch / master. – Fabien Haddadi Jan 04 '21 at 09:47
  • 4
    I think "pull request" comes from the perspective that you're asking whoever owns the branch you're targeting to "pull in" whatever commits you made to the branch you've been working on. I doubt the terminology quite so literally came from the names of the commands, so much as the underlying concepts. I think the "pull" terminology makes more sense the better an understanding you have of how git works, whereas the "merge" idea is far more intuitive to someone without any git background at all. Everyone knows, as least intuitively, what "merging" should mean, but pulling and pushing are jargon. – Marcel Besixdouze Jan 13 '21 at 20:26
  • "Pull request" sounds better even if I agree with all you guys say – Codii Apr 15 '21 at 13:34
62

They are the same feature

Merge or pull requests are created in a git management application and ask an assigned person to merge two branches. Tools such as GitHub and Bitbucket choose the name pull request since the first manual action would be to pull the feature branch. Tools such as GitLab and Gitorious choose the name merge request since that is the final action that is requested of the assignee. In this article we’ll refer to them as merge requests.

-- https://about.gitlab.com/2014/09/29/gitlab-flow/

rneves
  • 1,587
  • 21
  • 32
  • shouldn't merging be responsibility of the developer who is adding a new feature ? if a developer A adds a feature in feature_branch he should take the master branch and merge it ontop of his branch resolve all conflicts and test it out before creating the merge request ? – Ciasto piekarz Jan 30 '18 at 03:04
  • 2
    Yes but there's still a fast-forward merge that someone has to be done after that to get the code on to master. And actually I think on a team of full time devs it's probably best if the developer of the feature does that merge as well, but it might be useful for them to wait for someone to review their PR first. – bdsl Jun 05 '18 at 22:55
  • 1
    Normally, the code must merge without any conflicts, to be a valid "merge" request. – GC_ Jul 28 '20 at 15:07
46

In my point of view, they mean the same activity but from different perspectives:

Think about that, Alice makes some commits on repository A, which was forked from Bob's repository B.

When Alice wants to "merge" her changes into B, she actually wants Bob to "pull" these changes from A.

Therefore, from Alice's point of view, it is a "merge request", while Bob views it as a "pull request".

K. Symbol
  • 1,475
  • 12
  • 20
9

There is a subtle difference in terms of conflict management. In case of conflicts, a pull request in Github will result in a merge commit on the destination branch. In Gitlab, when a conflict is found, the modifications made will be on a merge commit on the source branch.

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

"GitLab resolves conflicts by creating a merge commit in the source branch that is not automatically merged into the target branch. This allows the merge commit to be reviewed and tested before the changes are merged, preventing unintended changes entering the target branch without review or breaking the build."

iclman
  • 858
  • 6
  • 14
  • Things have changed a bit since my previous post. I noticed that with Github Enterprise 2.21.6 (this might have changed in an earlier version), the behaviour is now as follows in case of conflict : a merge branch commit is created and the source branch is moved to that commit. Then, when the PR is resolved, a merge pull request commit is created. The destination branch is moved to that merge pull request commit. The merge branch commit and the merge pull request commit have different SHA1. However, they might not contain any difference if no change is made between the two commits. – iclman Dec 18 '20 at 10:14
  • Of course, I am talking about the default behaviour in Github. While doing merging your pull request, you are also given the option to squash your resulting commit, which would give another behaviour. – iclman Dec 18 '20 at 10:58
3

GitLab 12.1 (July 2019) introduces a difference:

"Merge Requests for Confidential Issues"

When discussing, planning and resolving confidential issues, such as security vulnerabilities, it can be particularly challenging for open source projects to remain efficient since the Git repository is public.

https://about.gitlab.com/images/12_1/mr-confidential.png

As of 12.1, it is now possible for confidential issues in a public project to be resolved within a streamlined workflow using the Create confidential merge request button, which helps you create a merge request in a private fork of the project.

See "Confidential issues" from issue 58583.

A similar feature exists in GitHub, but involves the creation of a special private fork, called "maintainer security advisory".

GitLab 13.5 (Oct. 2020) will add reviewers, which was already available for GitHub before.

VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
1

As mentioned in previous answers, both serve almost same purpose. Personally I like git rebase and merge request (as in gitlab). It takes burden off of the reviewer/maintainer, making sure that while adding merge request, the feature branch includes all of the latest commits done on main branch after feature branch is created. Here is a very useful article explaining rebase in detail: https://git-scm.com/book/en/v2/Git-Branching-Rebasing

Muhammad Shahbaz
  • 159
  • 1
  • 1
  • 10