Re: Git question: when using branches, how does git treat working files when changing branches?

[Ricardo Wurmus <rekado@elephly.net>]

Alan Mackenzie <acm@muc.de> writes:

> So, what happens to to changes in the working directory when changing
> branches?
> 1. git refuses to change branches because there are uncommitted changes.
> 2. git changes branches, discarding all uncommitted changes.
> 3. git changes branches, leaving the changes from the previous branch in
> the working directory.

It’s a mix of 1 and 3.

(A branch is just a pointer to a commit in the graph.  When creating a
branch you create a named pointer to the last commit (the one pointed to
by “HEAD”).  When you switch branches you really just tell git to travel
to the commit in the graph by following the named pointer.)

If there are new, uncommitted files in your working directory they will
remain as you switch branches.  Git refuses to switch to another branch
when the uncommitted file is created by a commit in the target branch,
so that you won’t accidentally lose the file.

For tracked files git will refuse to change branches:

~~~~~~~~
error: Your local changes to the following files would be overwritten by checkout:
	/path/to/the/modified/file.el
Please, commit your changes or stash them before you can switch branches.
Aborting
~~~~~~~

> What I really want to happen is
> 4. git maintains uncommitted changes separately in each branch.
>
> I suspect 4. is not the way git works.  So, how do I best simulate 4.?
> I would like to be able to move freely between git branches without
> suffering stupid restrictions like having to worry about preserving
> changes in the working directory.  Is there some variant of "git stash"
> which might do what I want?

Git only cares about commits and pointers to commits.  If you have
uncommitted changes and you want to make sure they are not lost as you
switch branches, the git way is to commit them, e.g.

    git add /path/to/the/modified/file.el
    git commit -m "WIP"
    git checkout the-other-branch

and then reset the last commit upon your return:

    git checkout first-branch
    git reset HEAD^
    
    # This means: reset to the parent commit of the commit that “HEAD”
    # points to.  The changes introduced by the commit remain in your
    # directory, but the commit is gone.

This is safe and you are very unlikely to ever lose your changes because
you created a commit object.  (It’s not easy to really lose commits by
accident.)

An alternative is to use “git stash” before switching and “git stash
pop” after your return.  You can have multiple stashes, but it’s easier
to get lost than it is with commits.

~~ Ricardo