Uncommitted changes followed a Git branch switch: inspect before committing
By ON Lab · Sources checked November 8, 2026
A branch switch does not automatically save a separate set of uncommitted edits for each branch. Git may carry compatible working-tree and index changes across the switch, while refusing a switch that would lose local changes. Check the current branch and both diffs before committing; a branch indicator changing is not proof that your pending edits were stored on the previous branch.
A reader saw the same staged file on two branches
A GitHub Community question describes staging a file on one branch, switching, and finding it staged on the other. The reader reproduced the behavior in an editor and a terminal. The answer distinguishes the current branch's commit history from the working tree and index in that checkout.
The official switch reference also says a clean index and working tree are not always required. It aborts an operation that would lose local changes unless additional behavior is explicitly requested. Thus neither “switch always discards” nor “switch always preserves everything” is an accurate operating rule.
Inspect the checkout before and after switching
git branch --show-current
git status --short
git diff
git diff --cachedThe branch check identifies the intended destination for a new ordinary commit. The ordinary diff and cached diff show different pending states. Record both if a file has been edited again after staging; a filename appearing in one group does not describe every version of it.
For two branch names pointing to the same commit, compatible pending changes can remain unchanged while the current branch changes. This does not mean both branches gained a commit or that Git secretly synchronized their history. Inspect the commit tips separately from the pending diff.
Our first local test: compatible staged changes followed
We committed app.txt with base content on main, created topic at that same commit, edited the file, and staged the change. Switching to topic succeeded. The working file retained the edited contents and the cached diff still contained the staged change.
At that point both branch tips still showed the initial commit. Only after we committed on topic did topic gain a new commit. Switching back to main then showed the original committed contents. This demonstrates why checking the branch immediately before committing matters.
The test used disposable files and example.invalid author configuration. It did not push to a remote, operate on a user's branches, or change global settings. We tested an ordinary tracked text file, not submodules or a sparse checkout.
Our second test: Git refused to overwrite local work
After the branches contained different committed versions of app.txt, we edited that path on main without committing. Switching to topic failed with a message that local changes would be overwritten. The current branch remained main and our local edit remained in the file.
That refusal is evidence to inspect, not a request to append a discard flag. Read which paths caused the conflict and decide where their contents belong. A command that worked while branch tips were identical does not guarantee that switching will work after their contents diverge.
Choose how to preserve unfinished work
| Intention | Possible approach | Required verification |
|---|---|---|
| Record a coherent change on the current branch | Review and commit it | Branch, staged diff, and resulting commit |
| Temporarily set work aside | Create an inspected stash | Tracked, untracked, and ignored-file scope |
| Work in another checkout | Use a deliberately managed separate working tree | Actual checkout and file ownership |
| Carry compatible edits intentionally | Switch and inspect again | Destination branch and both pending diffs |
These are choices, not a mandate to create a commit for every switch. If using a stash, first inspect what it captured. The untracked-file stash guide shows why a new file may remain outside the saved entry.
A separate working tree introduces its own paths and lifecycle. This article does not create one for you or claim that it copies unsaved editor buffers. Know which checkout you are editing before running a build or commit.
If you switched onto the wrong branch
Before committing, preserve and inspect the pending change. Verify the intended branch and whether switching there is safe. Do not discard content just to make the status panel look clean. If the change has already been committed, stop treating it as an uncommitted-state problem; moving or undoing a commit needs a separate review of history and sharing.
Similarly, an editor's unsaved buffer is another state outside Git's saved working file. Save or preserve it deliberately and compare what the Git commands actually read. A correct branch indicator cannot certify every open buffer's destination.
The completion check
Confirm that the intended branch is current, the relevant file has the intended contents, the staged diff contains exactly what should be committed, and the resulting commit appears on the intended branch. A successful switch is only one step.
Checked November 8, 2026. Both compatible staged-change switching and refusal to overwrite a conflicting local edit were reproduced in a disposable local repository. Editor buffers, remote history, submodules, and separate working trees were not tested.