If you've moved between GitLab and GitHub, you've hit this: one platform asks you to open a merge request, the other a pull request, and you wonder whether you're missing a feature. You're not. The two terms describe the same operation. This post covers what each one is, where the names came from, whether the features actually differ, and a few common questions.
The 60-second version
- A merge request (GitLab) and a pull request (GitHub) are the same thing: a request to review and merge one branch into another.
- GitHub's name comes from Git's own
git request-pullcommand. GitLab named it for the end action, thegit merge. - Both give you the same core workflow: a diff, discussion, reviews and approvals, CI/CD results, and a merge button.
- GitLab doesn't have "pull requests" and GitHub doesn't have "merge requests" — same idea, don't go looking for the other menu item.
What a pull request is (GitHub)
GitHub defines a pull request as a proposal to merge code changes into a project. In GitHub's own words, pull requests let you "discuss and review changes before merging them," which is the feature they describe as the foundation of collaboration on the platform. You open one by choosing a base branch (where the changes should land) and a compare branch (the work you did), and GitHub shows the diff, a conversation timeline, and the commits. Reviewers comment, request changes, or approve, and once it's ready you merge. The reference is GitHub's about pull requests documentation.
What a merge request is (GitLab)
GitLab's merge requests documentation defines them as "a central location for your team to review code, have discussions, and track code changes." Functionally that's the same list: you propose changes from a source branch into a target branch, the team reviews and discusses the diff, CI/CD pipeline results and mergeability show up on the request, reviewers approve it, and then it merges. GitLab leans on the abbreviation MR everywhere in its UI and docs, the way GitHub leans on PR.
Why the names differ
Both names describe the same request from two different angles: the mechanism versus the result.
Pull request comes from Git itself. Git ships a git request-pull command that, per the Git documentation, generates "a request asking your upstream project to pull changes into their tree." That's the original open-source contribution model: you publish your branch and ask a maintainer to pull it. GitHub built a web interface around that idea in 2008 and kept the vocabulary, so the name points at the mechanism — the maintainer pulls your work.
Merge request points at the outcome instead. What you're really asking for is a git merge: take my source branch and merge it into the target. GitLab named the feature after that end state, and the GitLab docs describe the whole thing in merge terms — review, approve, merge. Neither name is more correct; they just emphasize different halves of the same operation.
Do the features actually differ?
The naming is cosmetic. The capabilities are close enough that moving between them is a matter of relearning menu labels, not concepts. Both platforms give you a diff view, threaded discussion, line comments, required reviews and approvals, CI/CD status on the request, and a merge action with options like squash. Where they diverge is in the details of each platform's implementation and the words on the buttons, not in what a merge request or pull request fundamentally is.
The practical takeaway: if documentation written for one platform says "open a pull request" and you're on GitLab, read it as "open a merge request." The branch-review-merge steps map one to one. This also matters when you wire up tooling, because a Slack notifier or CI integration built for GitHub pull requests won't automatically speak GitLab merge requests, even though the workflow is identical. We mapped that exact gap in the GitLab equivalent of PullNotifier, and the full set of GitLab-to-Slack options in the GitLab Slack integration guide.
Full disclosure: we make PRFlow, which posts one updating Slack message per change with CI status and review comments. Because the workflow is the same on both platforms, PRFlow handles GitLab merge requests and GitHub pull requests the same way — helpful if your team lives on GitLab but a tutorial or teammate keeps saying "pull request." If you mostly need to stop losing MRs in Slack scrollback, that's what sharing merge requests is about.
Common questions
Is a merge request the same as a pull request?
Yes. A merge request on GitLab and a pull request on GitHub are the same workflow under different names: you push a branch, open a request to merge it into a target branch, and the team reviews and approves it before it merges. The terminology differs; the underlying Git operation is the same.
Does GitLab have pull requests?
No. GitLab calls the feature a merge request, not a pull request. If a tutorial written for GitHub tells you to open a pull request, open a merge request on GitLab instead. The steps are the same.
Why does GitHub call it a pull request?
The name traces to Git's own git request-pull command, which generates a request asking an upstream maintainer to pull your changes into their tree. GitHub built its web workflow around that idea and kept the name.
Bottom line
Merge request and pull request are the same feature wearing different labels. GitHub named it after how Git moves the code (pull), GitLab after what happens to it (merge). Learn one and you've learned both; the only real adjustment is swapping the word when you switch platforms, and making sure the tools around your workflow know which one they're talking to.