"J.V." <jvsrvcs@xxxxxxxxx> writes:
> OK so "work tree" is a new term for me. I thought we were in isolated
> sandboxes called "branches" and changes made in a branch would stay in
> that branch regardless.
Do not think of "branches" as isolated _sandboxes_.
Rather, "branches" are where the independent states are to be _recorded_.
The recorded states only exist in the git repository, and to use its
contents (e.g. view in the pager or browser, edit in the editor, run the
compiler on,...), you need to materialize the contents of the branch
somewhere on the filesystem. Such a set of files on the filesystem form
the working tree. The act of doing so is called "checking out a branch".
After you check out a branch, your working tree can be used to record an
updated state to the branch, but notice the "can be" part. Changes you
make to the working tree are _not_ associated to the branch until you make
them so by committing. They are floating on top of the branch you have
currently checked out in your working tree, and "floating" was the key
part lacking in your understanding that started this thread. You are
allowed to check out another branch while you have a local change in the
working tree, and this is deliberately so. People often start working on a
branch (that is, they want to make a change and check out a branch, or
they happen to have a check-out of a branch and then the find something
they want to change), and then realize that the change logically does not
belong to the currently checked-out branch but some other branch. They
need to be able to check out another branch without losing the change they
already made in their working tree, and for such usage, the workflow
should look like:
$ git checkout master ;# on master branch
$ edit hello.c ;# some feature being added
... realize that this change does not belong to the master
... branch but is part of the "hello" branch you have been
... working on for the past few days
$ git checkout hello ;# check out the correct branch
... this keeps the local modification in hello.c (as long as
... the file you modified are the same between master and hello
... branches). Keep working on it and then finally...
$ git commit ;# on hello branch.
There is another unrelated use case in which people have local changes in
their working tree, but need to check out a different branch. The most
common is while you are working on a large feature that is not finished
yet on your "feature" branch, you hear from your boss that one trivial fix
for an urgent bug must be committed and pushed out on the "master" branch.
The feature you have in your working tree does not have anything to do
with the bug or the fix you are going to make for your boss. In such a
case, you would want to save away the changes for the feature, check out
the "master" branch and commit the fix, i.e.
$ git checkout feature ;# on feature
$ edit foo bar baz ;# some complicated change
... boss comes
$ git stash ;# stash away the current change
or
$ git commit -a -m 'wip'
$ git checkout master ;# emergency
$ edit ... ;# quickfix
$ git commit -m 'urgent fix...'
... emergency dealt with
$ git checkout feature
... back to what was being worked on
$ git stash pop
or
$ git reset HEAD^
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html