Pull request vs Merge request

Question

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?

Specular

Answer 1

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.

Boggs

Does GitHub create an intermediate/temporary branch (invisible) when a pull request is made? – Noncontributory

@stevemao can we access them? Are they really read only as we can resolve conflicts on them? – Noncontributory

Of course you can access them. You can resolve them on your own branch. – Commonplace

What am I missing? pull = fetch + merge. If the final action is merge, then the first action must be fetch. – Fishbowl

@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 – Ungrateful

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 <implied merging>" - there's a clear winner here. – Metalloid

@Metalloid 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. – Lattice

"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. – Fulguration

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. – Accountancy

"Pull request" sounds better even if I agree with all you guys say – Sakhuja

Thanks @Boggs and Granitosaurus ! I was completely lost until I read your answer and comment. – Amaze

MR is a poor name imho. Since you can merge without fetching (you can merge an outdated branch into main with git merge if you fetched it a while ago, but a PR should never merge without fetching the branch. I think it's easier to remember and keep the distinction that pulling is not necessarily a merge, but pulling can involve merging, fast-forwarding, squash, or rebasing. I like to imagine as the target branch is pulling a rope, with the other end being the source branch. Since the strategy for integrating branches can be any one of: merge, rebase, or squash, merge is imho, not correct – Musk

In other words, merge is just one type of branch integration strategy out of several. – Musk

Totally agree with @Granitosaurus. "Pull" has totally different meaning for the two parties in such case (who is pulling is totally opposite), however, "Merge" means the same thing for both parties, even from the 3rd person's perspective, that a request is made to merge something into the main branch. The "Pull" is such confusing word for anyone. – Maus

The Pull of Pull Request is really ambiguous in that it is not clear who is pulling what. – Ulland

Answer 2

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".

Insectile

It reminded me of the example when I made the small report to let other colleagues know how git works. – Faso

perfect examination – Fatso

I don't care what Bob's doing. I'm merging my code to the main branch so it's a merge request. Bob might be dead for all I know so why would I consider it a pull request is beyond me. – Bellyache

@BojidarStanchev "request" means you ask someone else for it. Usually it's not your (Alice's) active work to merge of "your/their code into the main branch". Ask the owner of B to please-retrieve-and-work-in changes of A into B. Term "Pull" refers rather to the please-retrieve part, where merge refers to the please-work-in part. – Substitutive

@BojidarStanchev you're not merging your code into the main branch. Main branch is integrating (pulling) your code into the main branch. The action is performed in the context of the target branch's viewpoint, not from your viewpoint, you can't "push" to a branch that is usually protected so you can't "merge" into it either, but main can definitely merge your branch into itself, similarly it can also squash it or rebase it. In other words, main is pulling your changes into it via your request using whatever branching strategy the repo uses. – Musk

I second what @BojidarStanchev says. "Pull" has totally different meaning for both parties in such case, however, "Merge" means the same thing for both parties, even for the 3rd person's perspective, that a request is made to merge something into the main branch. The "Pull" is such confusing word for anyone. – Maus

Answer 3

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/

Septivalent

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 ? – Endanger

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. – Wilscam

Normally, the code must merge without any conflicts, to be a valid "merge" request. – Eccles

I've always found the "pull request" to be an hypocritical name. Because it only represents the start of the job, which could take days or even weeks. At the end of the... day, you'll still have to "merge in" your feature|hotfix|whatever branch into your upstream branch|main branch. This is really where your colleagues will want to review and check with you what you're going to merge in there. You shouldn't need to request to pull! This is obvious that you need to start to work! – Fulguration

Yes pull request is confusing. Context between the terms pull request and merge request do not bring me to the same understanding. That is until i read the definition. Maybe these terms can get standardized? – Ethelethelbert

Answer 4

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."

Kovno

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. – Kovno

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. – Kovno

Answer 5

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.

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.

Dome

Answer 6

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

Emulous