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

[Eli Zaretskii]

> Date: Wed, 28 Oct 2015 23:53:40 +0000
> From: Alan Mackenzie <address@hidden>
> Cc: address@hidden
> 
> > David Kastrup also suggested to commit your changes before switching
> > branches, I wonder why you ignored his advice.
> 
> It wouldn't work well for me.  The word "commit" has a meaning,
> something like "hand over on a permanent basis".  When you make a
> "commitment", you are pledging your honour that you will stand behind
> what you have committed.  What "commit" _doesn't_ mean is "temporarily
> store because there's nowhere better".  Of course there are ways of
> undoing a commit if it was done by mistake.  But routinely to commit to
> something with the intention of repudiating it later is an abuse.  It is
> the sort of thing politicians do.
> 
> Committed software and work in progress are two different categories of
> code.  To confuse them must lead to trouble.

I suggest that you rethink this concept.  What you describe makes
sense when using centralized VCS, where "commit" goes upstream and is
immediately made public; doing this with unfinished work is unwise, of
course.

But you are using a dVCS, where commits are local until pushed.
Moreover, I understand that your entire branch is local, which means
none of what you do on that branch is visible to anyone but you.  This
makes the grave meaning you seem to assign to a commit null and void.

In a dVCS, local commits are best used for your own personal tracking
of your work, a kind of log that is automagically linked to the code
changes you make as you go.  Which means, in particular, that you and
you alone determine when it's okay to commit, and the commit log
messages don't have to make sense to anyone but you.

Given all that, committing frequently on such a branch makes a lot of
sense, because it lets you track your work with much more fine-grained
resolution.  An immediate benefit is that you no longer need to depend
on your memory to remember when and why you made some change -- you
can see it with VCS commands, and you can put into the log messages
the rationale that will explain the "why" part.  Another significant
benefit is that bisecting bugs you find later gives much more precise
results, and, with good log messages, it's easy to quickly understand
why you made the offending change, and how to test the alternative
solution to be sure it doesn't break whatever reason that led you to
that change.

It goes without saying that even with this workflow, some commits are
"more equal" than others.  Examples include commits you make after you
finish testing some of your code, commits you make after a meaningful
part of the feature is done, etc.  But it's easy to indicate the
significance of these commits in the log messages, so they are later
easily identified in the commit log.  IOW, you have all the means to
support both "meaningful" commits and the less-meaningful ones.  The
latter kinds could have a log message such as

  Finished coding FOO, but didn't test it yet.

or even

  Wrote function 'foobar', but didn't try to compile it yet.

The messages make it clear these commits are unfinished WIP, but so
what? it's your own personal log that it's nobody's business to read.

> If I were were to commit unfinished changes just for lack of somewhere
> proper to store them, inevitably some of these changes would find
> themselves becoming permanent, embarassingly so.

This issue, if it bothers you, have an easy solution: when you are
done with your feature, instead of merging it onto master, _rebase_ it
on the master branch using Git's "rebase -i" command.  That allows you
to squash all your local commits into a single commit on master.  (The
exact procedure can be found via Google and is described under
"Interactive Mode" on the "git rebase" man page; search for "squash"
in that description.)

FWIW, I'm generally not bothered to have my local commits be visible
after I merge the feature branch, so I just use "git merge".  But
that's me; I know that some people don't like to show their local
history, and prefer "rebase".

Bottom line, a dVCS gives you some useful new functionalities, and
some of that justifies rethinking your old habits, in order to make
you work more convenient.  I think this is one of them.

P.S. I see that David wrote something very similar in spirit.