1083

Context: I'm working on master adding a simple feature. After a few minutes I realize it was not so simple and it should have been better to work into a new branch.

This always happens to me and I have no idea how to switch to another branch and take all these uncommited changes with me leaving the master branch clean. I supposed git stash && git stash branch new_branch would simply accomplish that but this is what I get:

~/test $ git status
# On branch master
nothing to commit (working directory clean)

~/test $ echo "hello!" > testing 

~/test $ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   testing
#
no changes added to commit (use "git add" and/or "git commit -a")

~/test $ git stash
Saved working directory and index state WIP on master: 4402b8c testing
HEAD is now at 4402b8c testing

~/test $ git status
# On branch master
nothing to commit (working directory clean)

~/test $ git stash branch new_branch
Switched to a new branch 'new_branch'
# On branch new_branch
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   testing
#
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (db1b9a3391a82d86c9fdd26dab095ba9b820e35b)

~/test $ git s
# On branch new_branch
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   testing
#
no changes added to commit (use "git add" and/or "git commit -a")

~/test $ git checkout master
M   testing
Switched to branch 'master'

~/test $ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   testing
#
no changes added to commit (use "git add" and/or "git commit -a")

Do you know if there is any way of accomplishing this?

Cœur
  • 32,421
  • 21
  • 173
  • 232
knoopx
  • 15,557
  • 7
  • 34
  • 41
  • 1
    Although there is a simpler solution to your problem, could you specify in what the result you get differs from what you wanted? – Gauthier Apr 02 '10 at 22:41
  • 2
    by doing the above or the answers at the bottom, the uncommited changes are on both master and the new branch. I want them only on the new branch, so I can checkout master and work on another thing without having these changes floating around – knoopx Apr 02 '10 at 22:56
  • 1
    see my edited answer. You need to commit your local changes on the new branch if you want to checkout a clean master. Local changes are only the differences between the current HEAD and your files on disk. These changes on local files are not versioned, you need to tell git to save them somewhere if you want to retrieve them later on. – Gauthier Apr 02 '10 at 23:07
  • 4
    possible duplicate of [Move existing, uncommited work to a new branch in Git](http://stackoverflow.com/questions/1394797/move-existing-uncommited-work-to-a-new-branch-in-git) – CL. Feb 09 '13 at 08:04
  • Does this answer your question? [Move existing, uncommitted work to a new branch in Git](https://stackoverflow.com/questions/1394797/move-existing-uncommitted-work-to-a-new-branch-in-git) – OverShifted May 11 '21 at 08:28

6 Answers6

1304

No need to stash.

Update 2020 / Git 2.23


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

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

git switch -c <new-branch>

The behavior remains unchanged.

Before Update 2020 / Git 2.23


git checkout -b new_branch_name

does not touch your local changes. It just creates the branch from the current HEAD and sets the HEAD there. So I guess that's what you want.

--- Edit to explain the result of checkout master ---

Are you confused because checkout master does not discard your changes?

Since the changes are only local, git does not want you to lose them too easily. Upon changing branch, git does not overwrite your local changes. The result of your checkout master is:

M   testing

, which means that your working files are not clean. git did change the HEAD, but did not overwrite your local files. That is why your last status still show your local changes, although you are on master.

If you really want to discard the local changes, you have to force the checkout with -f.

git checkout master -f

Since your changes were never committed, you'd lose them.

Try to get back to your branch, commit your changes, then checkout the master again.

git checkout new_branch
git commit -a -m"edited"
git checkout master
git status

You should get a M message after the first checkout, but then not anymore after the checkout master, and git status should show no modified files.

--- Edit to clear up confusion about working directory (local files)---

In answer to your first comment, local changes are just... well, local. Git does not save them automatically, you must tell it to save them for later. If you make changes and do not explicitly commit or stash them, git will not version them. If you change HEAD (checkout master), the local changes are not overwritten since unsaved.

Gauthier
  • 34,041
  • 11
  • 53
  • 87
  • This is how I always do it. It works exactly how you'd like it to. – synic Apr 02 '10 at 22:28
  • dude, I was missing this important point. I think I got why this happens and why git obviously can't ignore the changes (without forcing discard) if I don't commit them first. Thank you :D – knoopx Apr 02 '10 at 23:19
  • 36
    The confusing thing here is, that git’s man page states that `git checkout` “Updates files in the working tree to match the version in the index or the specified tree.”. That assumes your changes in your file system will be *GONE* afterwards. Without any chance to get them back. Even if you say they won’t, this still leaves a very bad feeling. I don’t trust this *at all*. Either the documentation is really bad or git’s default behavior is really dangerous. One should not have to trust on some “automagic” heuristic to detect that in this case you don’t want to lose your changes. – Evi1M4chine Aug 14 '13 at 16:48
  • 18
    If you are checking out a commit which would overwrite your local changes (if the history between the current commit and the target commit touches your locally modified files), git refuses. Only if `checkout` does not conflict with your local changes, the checkout works and leaves the local changes alone. I do understand the bad feeling though, the man page should maybe say "Updates unmodified files in the working tree". Git does not on the other hand make it too easy to lose local changes. `git checkout` either lets your local changes alone, or refuses if there is a conflict. – Gauthier Aug 22 '13 at 09:26
  • 1
    well, how would I checkout to another branch without bringing the local changes there? – アレックス Apr 23 '14 at 04:13
  • 6
    @Alex `git checkout -f`. You will lose your local changes without warning. – Gauthier Apr 23 '14 at 14:40
  • @Evi1M4chine That only applies when using `git checkout` to check out a branch though, right? If you type `git checkout .` git would overwrite all your changes in a heartbeat? – Hubro Aug 28 '15 at 05:41
  • 1
    I don't understand. According to my tests, 'git checkout -b new-branch-name' only puts the COMMITTED changes into the new branch. The question asks how to make a new branch with the UNcommitted (and UNadded) changes to a new branch. – SMBiggs Dec 11 '15 at 16:50
  • 1
    @Scott Biggs: a branch is noting more than a reference to a commit. Creating a new branch does not add any change to anything. Create a new branch with checkout -b, then commit what you want to be in the new branch. – Gauthier Dec 12 '15 at 10:27
  • 3
    @Evi1M4chine The first one. The documentation _is_ really bad. – Qwertie Apr 17 '16 at 06:18
  • @Gauthier put that "Edit" part to the top please, you will make people's work get removed, because local uncommited changes are removed unless you stash or sth – Jemshit Iskenderov Mar 23 '17 at 08:53
  • @JemshitIskenderov No, that's the whole point of the answer: checkout does not remove local uncommited changes. – Gauthier Mar 23 '17 at 09:07
  • @Gauthier i have lost once though, i wasn't using terminal command but using a tool. I have now tried example using terminal commands and it saved uncommited changes and i could commit changes on new branch – Jemshit Iskenderov Mar 23 '17 at 09:22
  • 1
    I found this issue: if i delete files on master, and create new branch (switch to it), those files you've deleted comes back. – Jemshit Iskenderov Apr 11 '17 at 08:04
  • And later you will probably want `git push -u origin new_branch_name` – Oliver Bock Apr 20 '18 at 02:32
65

Try:

git stash
git checkout -b new-branch
git stash apply
Grant Limberg
  • 19,335
  • 10
  • 59
  • 84
  • 6
    Is this different to just doing 'git checkout -b new-branch' by itself? – Adrian Mouat Jul 11 '13 at 10:09
  • I don't think it was when the answer was originally written, but I could be wrong. Unfortunately due to my working circumstance, I've been using perforce for the last few years so I cannot attest to it's accuracy now. – Grant Limberg Jul 12 '13 at 04:07
  • 7
    Or instead of the last two steps: git stash branch new-branch – rethab Jul 09 '14 at 05:26
  • 1
    git stash is no longer required – kory Sep 20 '16 at 16:57
  • When you have an already existing branch where you want to put all your stuff, stash makes sense for me: (Eventually git fetch --all; to get the remote branch on origin) git stash; git checkout ; git stash apply; – Paolof76 Oct 14 '16 at 08:52
  • you still have to commit them though from not showing up in master – Muhammad Umer Apr 24 '18 at 04:17
25

Two things you can do:

git checkout -b sillyname
git commit -am "silly message"
git checkout - 

or

git stash -u
git branch sillyname stash@{0}

(git checkout - <-- the dash is a shortcut for the previous branch you were on )

(git stash -u <-- the -u means that it also takes unstaged changes )

Pylinux
  • 9,386
  • 3
  • 52
  • 62
14

If you want your current uncommited changes on the current branch to move to a new branch, use the following command to create a new branch and copy the uncommitted changes automatically.

git checkout -b branch_name

This will create a new branch from your current branch (assuming it to be master), copy the uncommited changes and switch to the new branch.

Add files to stage & commit your changes to the new branch.

git add .
git commit -m "First commit"

Since, a new branch is created, before pushing it to remote, you need to set the upstream. Use the below command to set the upstream and push it to remote.

git push --set-upstream origin feature/feature/NEWBRANCH

Once you hit this command, a new branch will be created at the remote and your new local branch will be pushed to remote.

Now, if you want to throw away your uncommited changes from master branch, use:

git checkout master -f

This will throw away any uncommitted local changes on checkout.

Maverick
  • 1,243
  • 15
  • 29
7

If you are using the GitHub Windows client (as I am) and you are in the situation of having made uncommitted changes that you wish to move to a new branch, you can simply "Crate a new branch" via the GitHub client. It will switch to the newly created branch and preserve your changes.

enter image description here

Tod Birdsall
  • 14,162
  • 4
  • 33
  • 38
1

In the latest GitHub client for Windows, if you have uncommitted changes, and choose to create a new branch.
It prompts you how to handle this exact scenario:

enter image description here

The same applies if you simply switch the branch too.

Arsen Khachaturyan
  • 6,472
  • 4
  • 32
  • 36
Jerry Dodge
  • 25,720
  • 28
  • 139
  • 301