git git-branch git-reset git-stash

Move existing, uncommitted work to a new branch in Git


I started some work on a new feature and after coding for a bit, I decided this feature should be on its own branch.

How do I move the existing uncommitted changes to a new branch and reset my current one?

I want to reset my current branch while preserving existing work on the new feature.



Update 2020 / Git 2.23

Git 2.23 adds the new switch subcommand in an attempt to clear some of the confusion that comes from the overloaded usage of checkout (switching branches, restoring files, detaching HEAD, etc.)

Starting with this version of Git, replace the checkout command with:

git switch -c <new-branch>

The behavior is identical and remains unchanged.

Before Update 2020 / Git 2.23

Use the following:

git checkout -b <new-branch>

This will leave your current branch as it is, create and checkout a new branch and keep all your changes. You can then stage changes in files to commit with:

git add <files>

and commit to your new branch with:

git commit -m "<Brief description of this commit>"

The changes in the working directory and changes staged in index do not belong to any branch yet. This changes the branch where those modifications would end in.

You don’t reset your original branch, it stays as it is. The last commit on <old-branch> will still be the same. Therefore you checkout -b and then commit.


  • 18

    Just to make sure, I need to commit the unfinished feature BEFORE I reset my original branch? Or will those uncommitted files be preserved regardless of committing?

    Sep 8, 2009 at 16:02

  • 211

    FYI: changes in working directory and changes staged in index do not belong to a branch. git checkout -b <new branch> changes where those changes would end in.

    Sep 8, 2009 at 17:00

  • 160

    If you already have a branch and want to move your changes to the existing branch, checkout…

    – Chirantan

    Jan 25, 2011 at 8:41

  • 18

    If you want to push your new branch to the remote repository:…

    – Dewayne

    Dec 13, 2013 at 2:15

  • 12

    @JDSmith: uncommit changes do NOT belong to any branch. They only reside in the working directory git checkout ./git reset --hard will unrecoverably remove them

    – knittl

    Nov 5, 2015 at 6:33



  1. Save current changes to a temp stash:

    $ git stash

  2. Create a new branch based on this stash, and switch to the new branch:

    $ git stash branch <new-branch> [email protected]{0}

Tip: use tab key to reduce typing the stash name.


  • 67

    If the other branch already exists, you can just switch to it with checkout, then git stash apply.

    – Archonic

    Dec 21, 2015 at 18:27

  • 6

    I don’t understand the tip “Tip: use tab key to reduce typing the stash name.”. Isn’t “[email protected]{0}” the name? I cannot run it successfully.

    – Herbert

    Apr 7, 2017 at 3:58

  • 8

    Why is this better than the accepted answer ?

    May 30, 2017 at 23:17

  • 11

    I don’t understand why this is better then the accepted answer of git checkout -b <new branch name>

    – Noitidart

    Aug 11, 2017 at 5:32

  • 7

    You don’t need to git add -A before stashing.

    – vichle

    Feb 10, 2018 at 13:09


If you have been making commits on your main branch while you coded, but you now want to move those commits to a different branch, this is a quick way:

  1. Copy your current history onto a new branch, bringing along any uncommitted changes too:

     git checkout -b <new-feature-branch>
  2. Now force the original “messy” branch to roll back: (without switching to it)

     git branch -f <previous-branch> <earlier-commit-id>

    For example:

     git branch -f master origin/master

    or if you had made 4 commits:

     git branch -f master HEAD~4

Warning: git branch -f master origin/master will reset the tracking information for that branch. So if you have configured your master branch to push to somewhere other than origin/master then that configuration will be lost.

Warning: If you rebase after branching, there is a danger that some commits may be lost, which is described here. The only way to avoid that is to create a new history using cherry-pick. That link describes the safest fool-proof method, although less convenient. (If you have uncommitted changes, you may need to git stash at the start and git stash pop at the end.)


  • 6

    This answers a question which is slightly different from what the op asked. I decided to put this answer here because this is where Google brought me when I was searching for an answer. The actual question that deals with this situation is here.

    Dec 28, 2016 at 4:49