How to rebase a GitLab merge request, and when you have to

Your merge request is approved and the pipeline is green, but GitLab won’t merge it until you rebase. Here is why, and every way to rebase a GitLab merge request in 2026: in the browser, with a quick action, from glab or the API, and locally when there are conflicts.

When GitLab asks for a rebase

It depends on the project’s merge method, set by a Maintainer in Settings › Merge requests:

Merge method	Needs a rebase?
Merge commit	Never
Merge commit with semi-linear history	When the target branch has commits your branch doesn’t
Fast-forward merge	When the target branch has commits your branch doesn’t

The last two merge only a source branch that’s up to date with the target branch. When it isn’t, the merge widget says Merge blocked and lists “Fast forward merge is not possible. Please rebase.”, and the API reports detailed_merge_status as need_rebase. More blocking reasons in why can’t I merge my GitLab merge request?

Rebase in GitLab

If the rebase is conflict-free, GitLab can do it for you:

• Select Rebase in the merge request, or
• comment /rebase.

GitLab rebases the source branch onto the latest commit of the target branch in the background, and the rebased branch gets a new pipeline. You need permission to push to the source branch, and the branch must not be protected from force pushes. The Rebase button only appears when the merge method needs a rebase; /rebase, glab and the API work with any merge method. A rebase GitLab does rewrites the commits on the server, so they lose their GPG signatures; if the project requires signed commits, rebase locally.

GitLab can’t rebase for you when the branches conflict. /rebase then answers “This merge request is currently in an unmergeable state, and cannot be rebased”, which also covers a source branch with no commits, a missing target branch, or no diff. It can also answer that the branch is protected from force push, or that a rebase is already in progress. If you can’t push to the source branch, or the merge request is closed, /rebase does nothing at all. In a comment that also contains /merge, GitLab ignores the /merge, so the branch isn’t merged before it’s rebased.

Rebase without a pipeline

To save runner time, select Rebase without pipeline. It sits next to Rebase on the merge widget’s “Fast forward merge is not possible” row, for anyone who can push to the source branch, and like Rebase it only succeeds if the rebase is conflict-free. It isn’t offered when Pipelines must succeed is on, unless Skipped pipelines are considered successful is on too.

From glab or the API

glab mr rebase 123
glab mr rebase 123 --skip-ci

Without an ID, glab mr rebase rebases the merge request for your current branch.

The API queues the same rebase:

curl --request PUT \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/76/merge_requests/1/rebase?skip_ci=true"

It answers 202 with {"rebase_in_progress": true}. To see when it’s done, poll the merge request with include_rebase_in_progress=true until rebase_in_progress is false, then check merge_error: it’s null on success. A 403 means you can’t push to the source branch, it’s missing, or it’s protected from force pushes. glab and the API skip the pipeline even when Pipelines must succeed is on, but that setting then blocks the merge until a pipeline passes.

Rebase locally, when there are conflicts

git fetch origin
git switch my-branch
git pull --ff-only
git branch my-branch-backup
git rebase origin/main
# resolve the conflicts, then:
git add .
git rebase --continue
git push --force-with-lease origin my-branch

git pull --ff-only picks up commits added on GitLab since you last fetched, such as applied suggestions, so the rebase includes them. --force-with-lease overwrites the branch on GitLab only if it still matches your origin/my-branch, so a push you haven’t fetched makes it fail instead of disappearing. Editors that fetch in the background defeat that check; add --force-if-includes to keep it. During the rebase, git rebase --abort stops it and restores the branch; after it, git reset --hard my-branch-backup puts the branch back. A protected source branch rejects the force push unless its rule turns on Allowed to force push; see why GitLab says you’re not allowed to push to a protected branch. For conflicts you’d rather resolve in the browser, see how to resolve merge conflicts in GitLab.

Let GitLab rebase at merge time

With the semi-linear or fast-forward method, a Maintainer or Owner can select Enable automatic rebase prior to merge in Settings › Merge requests, under Merge method. GitLab then rebases a copy of the source branch at merge time, without rewriting your branch, and the merge widget stops asking for a rebase. It’s generally available since GitLab 19.2.

Know the trade-offs:

• The pipeline doesn’t run again on the rebased result, so what merges can differ from what was tested. Merge trains (Premium and Ultimate) test the rebased result first.
• It needs a conflict-free rebase.
• The server-side rebase removes GPG signatures from commits.

Approvals after a rebase

A rebase makes you the committer of every rebased commit, while the authors stay the same. If the project prevents approvals by users who add commits (Premium and Ultimate), your approval stops counting after you rebase. The commits’ authors can’t approve either, rebase or not.

If the project removes all approvals when commits are added to the source branch, a local rebase and force push can remove existing approvals, because a rebase often changes the diff that GitLab compares.

On your phone

MergeBell’s merge sheet lists every reason GitLab gives for blocking a merge, a needed rebase included, before you tap Merge. Approve, merge, squash and auto-merge are all on the free tier. See how to review a GitLab merge request on your phone.