Skip to main content
DevOps Insightsguides & answers

Git · troubleshooting

error: cannot rebase: You have unstaged changes

git rebase or git pull --rebase found uncommitted changes to tracked files and stopped before changing anything. Commit them, stash them, or rebase with --autostash.

Reproduced on Git 2.50.1, . Where the text says “reproduced”, the behaviour was run on that version, not taken from documentation.

First published

New to this? Read what is actually happening first, then come back to the steps.

On this page · 9 sections

Before you start

  • A terminal in the repository.

Run this first

step 1 of 2
git status --short

Look for M entries; ?? entries (untracked) do not block a rebase

Shows exactly what counts as uncommitted.

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Narrow it down

0 answered · nothing is sent anywhere

What does git diff --summary or git status show?

Cause space

3 of 3 still possible

  • You have uncommitted editsCommon
  • Only a file mode changedOccasional
  • A tool keeps changing a tracked fileOccasional

Nothing ruled out yet. Answer the question above and the branches your answer eliminates will strike through here.

Or diagnose it manually

In this order. The first command usually contains the whole answer.

  1. Step 1

    git status --short

    Shows exactly what counts as uncommitted.

    Look for M entries; ?? entries (untracked) do not block a rebase

  2. Step 2

    git stash list

    After an autostash or a stash, confirms nothing was left behind.

    Look for No leftover entry once your edits are back

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

You have uncommitted edits

Common

Work in progress in tracked files, staged or not.

Confirm

git status --short

M in either column next to a file

Fix

  • Commit them first if they belong on the branch: git commit -am "…", then rebase.
  • Or stash around the rebase: git stash, git rebase main, git stash pop.
  • Or in one step: git rebase --autostash main (or git pull --rebase --autostash), then check git status for conflicts.
git rebase --autostash main

Reproduced on Git 2.50.1 and 2.43.0: printed Applied autostash; a staged edit came back unstaged.

Only a file mode changed

Occasional

chmod on a tracked file, or a filesystem that reports every file as executable (a mounted Windows drive, some containers), counts as a change.

Confirm

git diff --summary

mode change 100644 => 100755

Fix

  • If the mode change is wanted, commit it. If not, undo it with chmod.
  • On filesystems that cannot store the executable bit, set git config core.fileMode false for that clone.

A tool keeps changing a tracked file

Occasional

A formatter, IDE, build or package manager rewrites a tracked file, so the tree is never clean when the rebase starts.

Confirm

git diff --stat

A generated or lock file you did not edit by hand

Fix

  • Commit the change if it is legitimate, or restore the file with git restore FILE if you are sure it is disposable.
  • If the file is build output, stop tracking it and add it to .gitignore.

Understanding it properly

Skip this if you are mid-incident — the working part of the page is above. Worth reading afterwards, because understanding the mechanism is what stops the next one.

In plain terms

A rebase rewrites your branch commit by commit, and it needs the files on disk to match the last commit while it does that. You have edits that are not committed, so Git refuses rather than risk mixing them in. Put the edits somewhere safe first, then rebase.

Words used on this page

Unstaged change
An edit to a tracked file that has not been added with git add.
Index
The staging area: what git add has prepared for the next commit.
Autostash
Stash local changes before the rebase and re-apply them after it, in one command.
What is actually happening

Reproduced on 23 October 2026 with Git 2.50.1 on macOS and Git 2.43.0 on Ubuntu 24.04. An edited tracked file made git rebase print error: cannot rebase: You have unstaged changes. and error: Please commit or stash them., exit 1, with nothing changed. With the edit staged the wording was Your index contains uncommitted changes. git pull --rebase gave the same message as cannot pull with rebase, exit 128.

Untracked files did not block the rebase. A permission change did: chmod +x on a tracked script showed up as old mode 100644, new mode 100755 in git diff and stopped the rebase just like an edit.

git rebase --autostash, or rebase.autoStash set to true, stashed the edit, rebased and printed Applied autostash. An edit that had been staged came back unstaged, so check git status before committing.

How to tell this is your problem
WhereWhat you see
git rebaseerror: cannot rebase: You have unstaged changes. error: Please commit or stash them.
git pull --rebase, or pull.rebase=trueerror: cannot pull with rebase: You have unstaged changes.
Staged changeserror: cannot rebase: Your index contains uncommitted changes.

How to know it is actually fixed

  • The rebase finishes with Successfully rebased, and git status shows your edits again.

Stopping it happening again

  • If you always want this, set git config rebase.autoStash true (and pull.rebase true if you pull with rebase).
  • Commit small and often, so a rebase rarely meets work in progress.

Security considerations

  • git reset --hard and git checkout -- FILE discard uncommitted edits with no way back. Stash or commit instead unless you are sure.

Sources

Behaviour described here is drawn from official documentation. Where a figure could not be confirmed on an official page it is attributed in the text rather than stated as canonical.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it

Where to go next