Git
Branching
Uncommitted Changes
Version Control
Git Tips

Git Create a branch from unstaged/uncommitted changes on master

Master System Design with Codemia

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

Introduction

If you started editing on master or main by mistake, you usually do not need to stash or commit first. Git can create a new branch at your current HEAD and carry your unstaged and uncommitted changes with you.

The Simple Fix

If the goal is "take my current working tree and put it on a new branch," the direct command is:

bash
git switch -c feature/my-work

On older Git versions, the equivalent is:

bash
git checkout -b feature/my-work

Your working tree and index stay as they are. The only change is that HEAD now points at the new branch instead of master.

Why This Works

A branch is just a movable reference to a commit. Uncommitted changes live in your working tree and index, not inside the branch itself. When you create and switch to a new branch, Git does not throw away those edits. It simply changes which branch name is attached to the current commit.

That means this workflow is safe in the common case:

bash
git status
git switch -c feature/my-work
git status

After the switch, the modified files are still there, but now they are associated with your new branch.

When You Might Want to Stash Instead

Sometimes you want a clean master immediately and are not ready to keep the changes checked out on the new branch. In that case, stashing is a separate option:

bash
git stash push -m "wip on master"
git switch -c feature/my-work
git stash pop

That is more typing, so do it only when you actually need the temporary clean state or you expect conflicts while switching contexts.

What If You Already Committed on master

The answer changes if the work is already committed. In that case, you create the branch at the current commit first:

bash
git switch -c feature/my-work

Then, if you want master to go back to its previous state and the commit has not been shared, you can move master later. If the commit is already pushed, the safer cleanup is usually git revert rather than rewriting shared history.

For uncommitted work, though, there is no need for any history surgery. Just switch to a new branch and keep going.

A Practical Recovery Flow

This is a reliable sequence when you notice the mistake:

bash
1git status
2git switch -c feature/my-work
3git add .
4git commit -m "Start feature work"

If you want to be extra careful, inspect first:

bash
git branch --show-current
git diff

That makes it obvious what branch you are on and what changes are currently uncommitted before you create the new branch.

Common Pitfalls

  • Stashing automatically even when it is unnecessary. For plain uncommitted changes, git switch -c is usually enough.
  • Forgetting that branch creation happens at the current HEAD. If master is behind where you expect, create the branch only after confirming the current commit.
  • Mixing untracked files into the workflow without checking git status. Those files come with you too, but they are easy to overlook.
  • Resetting master aggressively after creating the branch. If the work was never committed, there is nothing on master history to reset.
  • Using old advice that rewrites history when the problem is only a dirty working tree. Keep the fix proportional to the mistake.

Summary

  • To move uncommitted work off master, create and switch to a new branch with git switch -c <name>.
  • Your unstaged and staged changes come with you because they live in the working tree and index.
  • Stash only when you specifically need a temporary clean state.
  • The workflow is different only if the work is already committed.
  • Check git status first, then apply the smallest fix that preserves your work.

Course illustration
Course illustration

All Rights Reserved.