Pull request vs merge request: two names, one thing
A pull request and a merge request are the same thing: a request to merge one branch into another, reviewed before it lands. GitHub calls it a pull request. GitLab calls it a merge request.
This explainer is by GitLoom, a Slack-first pull request notification tool that watches your GitHub repos and sends one quiet daily digest of which pull requests are stuck.
Same feature, different label
On every major code host, the workflow is identical. You branch off main, make your changes, push, and open a request asking for those changes to be reviewed and merged. Teammates comment, you push fixes, someone approves, and the branch merges.
GitHub, Bitbucket, and Azure DevOps call that request a pull request (PR). GitLab calls it a merge request (MR). There is no functional difference: not in what it contains, not in how review works, not in what happens when someone clicks merge.
So if you came here to settle a team argument: nobody is wrong. The two names describe the same object from opposite ends. A pull request asks the maintainer to pull your branch. A merge request asks for your branch to be merged. Same branch, same review, same merge.
Where the two names come from
The mailing list era
Git ships with a request-pull command. You pushed your branch to a public repository, then emailed the maintainer asking them to pull from it. The Linux kernel still works this way.
GitHub picks "pull"
GitHub launches and builds a review interface around that ask. The name pull request keeps the maintainer’s point of view: someone is requesting that you pull their changes.
GitLab picks "merge"
GitLab launches and names the same feature a merge request, taking the author’s point of view: you are requesting that your branch be merged.
Two names, one workflow
Bitbucket and Azure DevOps went with pull request. Gerrit calls it a change. The vocabulary never converged, but the workflow did: branch, request, review, merge.
GitHub and GitLab, translated
The naming split goes past pull request vs merge request. Here is the vocabulary, side by side.
| Concept | GitHub says | GitLab says |
|---|---|---|
| The review request | Pull request | Merge request |
| Its abbreviation | PR | MR |
| Not ready for review yet | Draft pull request | Draft merge request |
| Where the code lives | Repository | Project |
| A collection of repositories | Organization | Group |
| Built-in CI | GitHub Actions | GitLab CI/CD |
| Merging one at a time, safely | Merge queue | Merge train |
| Mandatory sign-off | Required reviewers | Approval rules |
| Sharing a snippet of code | Gist | Snippet |
When to use each term
Say pull request when...
Your team is on GitHub, Bitbucket, or Azure DevOps. Their interfaces, APIs, and docs all say pull request, and PR is the shorthand your teammates already use.
Say merge request when...
Your team is on GitLab. Its interface, API, and webhooks say merge request and MR. Writing PR in GitLab docs just confuses whoever joins next.
In mixed company...
Pull request is the safer generic term; GitLab users understand it. Writing docs that cover both platforms? Pick one, note the other once, and move on.
Stuck is stuck, under either name
Whatever your platform calls it, the failure mode is identical. A branch is ready, a request is opened, and then it sits. Waiting for a first review. Approved but never merged. Red on failing CI since the last push. Quietly collecting merge conflicts while main moves on. The name on the button does not change the week-old PR at the bottom of the list.
That is the problem GitLoom exists for. It watches your GitHub repos and posts one quiet digest to Slack on weekday mornings, so stuck pull requests surface before they turn into standup archaeology.
Good morning. 4 pull requests need a nudge across 3 repos:
Waiting on first review: api#482 Add rate limiting to webhook delivery (Priya)
Opened Monday, still no first review. Marcus touched this code last.
Approved, not merged: billing#517 Migrate billing webhooks to v2 (Jonas)
Sara approved it two days ago. One click from shipping.
Merge conflict: web#495 Refactor session storage (Ale)
Conflicts with main since yesterday’s auth merge. Needs a rebase.
Failing CI: api#490 Upgrade the payments SDK (Marcus)
CI has been red since yesterday: two unit tests. Green checks are all that stand between this and merge.
Everything else is moving normally. Nothing else needs you today.
One quiet digest, not forty notifications.
One quiet digest, weekday mornings
A single Slack message lists the pull requests that need a nudge: waiting on a first review, approved but unmerged, in merge conflict, failing CI, or small and forgotten.
Silent when nothing is stuck
If nothing changed, GitLoom says nothing. Repeat reminders are batched every few days so the channel stays readable.
Plain English, not event spam
Each line says why the PR is stuck and what would unblock it, instead of forwarding every push, comment, and label change.
Lives where your team already reads
Digests go to Slack, email, or Telegram. No new dashboard to check and no new habit to build.
From naming trivia to a quieter channel, in two minutes
Install the GitHub App
Grant access to the repositories you want watched. Repos you grant during install are tracked automatically.
Connect Slack
Authorize GitLoom in your workspace. It only posts what you turn on.
Pick a channel
Choose where the digest lands, for example #eng. The first one arrives the next weekday morning.
Pull requests, merge requests, and GitLoom
The short answers, for people who scrolled straight here.
Whatever you call them, stop losing them.
GitLoom watches your GitHub repos and tells you each weekday morning which pull requests are stuck.
Two minutes to install · 14 days free · Quiet by default