Git
Version Control
Branching
Git Workflow
Software Development

Move existing, uncommitted work to a new branch in Git

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

Starting work on the wrong Git branch is common, and in most cases the fix is simple. Uncommitted changes live in your working tree and index, not in branch history yet, so they usually move with you when you create and switch to a new branch. The safest recovery depends on whether the changes are unstaged, staged, blocked by checkout conflicts, or already committed.

The Usual Fix Is git switch -c

If Git allows the branch switch, the simplest solution is to create a new branch from the current commit and carry the working tree changes with you.

bash
git status
git switch -c feature/auth-timeout

After that, your modified files are still there, but now you are on the correct branch. You can stage and commit normally.

bash
git add .
git commit -m "Handle timeout retry behavior"

This should be the first attempt because it is the lowest-risk path.

Use stash Only When the Branch Switch Is Blocked

Sometimes Git refuses to switch because the target branch would overwrite your current changes. In that case, stash the work, create the branch, and restore it there.

bash
git stash push -u -m "wip auth timeout"
git switch -c feature/auth-timeout
git stash pop

The -u flag matters because it includes untracked files. Without it, new files can be left behind and the move feels incomplete.

If conflicts appear during stash pop, resolve them like merge conflicts. The key point is that the stash is only a fallback when a direct branch creation is blocked.

Staged Work Moves Too

If you already staged some changes, git switch -c preserves that state. This is useful when you intentionally prepared part of the commit and want to keep that work intact.

If you later realize the branch should contain multiple clean commits rather than one large one, use interactive staging.

bash
1git switch -c feature/auth-timeout
2git add -p
3git commit -m "Add retry policy"
4git add -A
5git commit -m "Add telemetry for retry failures"

That keeps the history reviewable without redoing your work.

If You Already Committed on the Wrong Branch

Once the work is committed, the problem changes. The usual move is to create the new branch at the current commit first.

bash
git switch -c feature/auth-timeout

Now the commit is on the right branch too. If the commit should no longer remain on the original branch and it has not been shared, you can move the old branch pointer back.

bash
git switch main
git reset --hard HEAD~1

That command is destructive and safe only if the commit has not been pushed or shared. If it has been shared, use a safer history-preserving approach such as revert or coordinated rewrite.

A Temporary WIP Commit Can Be Safer Than a Stash

Some developers prefer a temporary commit because it is easier to recover through reflog than a stash they forgot about.

bash
git add -A
git commit -m "WIP: move to feature branch"
git switch -c feature/auth-timeout

You can later squash or amend that commit into cleaner final history. This is especially useful when the working tree is large and you want a clearly recoverable checkpoint before moving things around.

Verify Before the First Push

Before pushing the new branch, quickly verify the branch name, recent commits, and diff against the intended base.

bash
git branch --show-current
git log --oneline --decorate -n 5
git diff main...HEAD --stat

That short check catches wrong-branch mistakes before they become pull request cleanup work.

Common Pitfalls

  • Using git reset --hard before confirming the work exists safely on another branch or in a stash.
  • Forgetting -u when stashing and leaving untracked files behind.
  • Treating stash as the first tool even when git switch -c would have worked directly.
  • Combining unrelated edits into one recovery commit and making later cleanup harder.
  • Skipping verification and discovering the branch mistake only after opening a pull request.

Summary

  • For ordinary uncommitted work, git switch -c new-branch is usually enough.
  • If switching is blocked, stash including untracked files and restore on the new branch.
  • Staged changes move with the branch switch too.
  • If the work is already committed, move the commit to the right branch before cleaning the old one.
  • Verify branch, commits, and diff before the first push.

Course illustration
Course illustration

All Rights Reserved.