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:

Although there is a simpler solution to your problem, could you specify in what the result you get differs from what you wanted?
– GauthierApr 2 '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
– knoopxApr 2 '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.
– GauthierApr 2 '10 at 23:07

4 Answers
4

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.

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.

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.
– Evi1M4chineAug 14 '13 at 16:48

12

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.
– GauthierAug 22 '13 at 9:26

1

well, how would I checkout to another branch without bringing the local changes there?
– アレックスApr 23 '14 at 4:13

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.
– Scott BiggsDec 11 '15 at 16:50

Is this different to just doing 'git checkout -b new-branch' by itself?
– Adrian MouatJul 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 LimbergJul 12 '13 at 4:07

4

Or instead of the last two steps: git stash branch new-branch
– rethabJul 9 '14 at 5:26

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.