On Tue, 3 Sep 2013 06:44:34 -0700 (PDT)
maya melnick <maya778...@yahoo.com> wrote:
> but in my case when I switch back to branch master the changes I made
> in branch 'test' do not get reverted.... I look in the dir and the
> one file I added in branch 'test' is still there when I have switched
> to branch 'master'...
> (I haven't commited, it's just a test branch, I don't want to
> commit....;-) make sense?
In Git model, no, this does not make sense, and you're facing a very
common confusion, so fear not ;-)
In Git, the work tree -- the place where you modify your files and from
where you `git add` them to the staging area -- does not "belong" to
any branch. It's always *based* on some commit (the one referenced to
by HEAD) but it does not belong to that commit.
Hence the changes you make in your work tree are just that -- the
changes in your work tree; they are called "local changes".
You might stage them for the next commit by `git add`-ing files with
local changes, and then they become "staged changes" but even they are
not part of any branch yet.
Finally you might decide to commit the staged changes by running
`git commit`, and *only then* the recorded commit is used to update
(promote) a branch, and only then these changes start to be "on a
The stashed changes do not belong to any branch as well (though they
"know" which branch they are based on).
So there are two (basic) ways to deal with local changes when you want
to switch to another branch:
1) Stash them. You could `git stash pop` them back when you switch
back to the original branch.
2) Throw-away commits (somethimes called "work-in-progress" or just
"WIP" commits) -- before switching a branch just commit all your
changes and make this fact clear in the commit message (for instance,
by prepending the "WIP" prefix to the commit message. Then change
the branch. After checking out the original branch just do
git reset HEAD^
and viola -- the tip commit of the currently checked out branch is
gone as if you have never recorded it while all its changes are
retained in your work tree and the index.
There are other possibilities as well:
* You can check out another branch while having local changes in your
tree. Git will attempt to reconcile these changes with those it's
about to bring in from the branch being switched to, and this might
result in conflicts. Anyway this might be useful in a number of
cases including the "oops I did this local changes on a wrong
* (Hardcore) It it possible to have several parallel separate work trees
and staging areas, so that each pair of them has a different branch
checked out. But while possible, this is employed only in very
specialized cases, and yours is not one of them.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.