Normally when you:
git checkout foo- Modify a file
git checkout bar
Git will tell you that you can’t change branches because you have un-committed modifications. (I don’t have the exact message in front of me, but it’s something to that effect). You then normally use git stash to get rid of those modifications, and you’re on your merry way.
My coworker (who is new to Git and therefore is not intentionally doing anything advanced) doesn’t have that behavior. On her machine, when she does git checkout bar, it just moves the modifications that she made on foo into bar. This is very confusing to me, as I’ve been using Git for at least a year now and never seen it behave that way.
What could my coworker possibly have done to make it so that Git simply moves un-added/un-committed modified files between branches, rather than complaining and requiring git stash?
(I just wrote up the following text here for coworkers yesterday who are new to Git. Hope it helps.)
If you have made changes to files on branch A and want to switch to branch B (which is unrelated), then it’s a good idea to commit the changes to branch A first. This way, the changes will still be on branch A when you come back to it later. (Another option is called “stashing”, which is useful in some situations – see http://schacon.github.com/git/git-stash.html for more information.)
If you don’t commit the changes first, then there are two situations that can arise. Consider a file “file.txt”, and branches A and B. The two situations are:
If you have more than one changed file, then any file in situation (2) will prevent a branch switch.
Finally, if you want to discard modifications to a file, use a command like “git checkout — file.txt”. This will throw away any uncommitted modifications to file.txt and restore it to the latest committed version from your current branch.