

Using the git index to fearlessly try out risky changes - comatose_kid
http://osteele.com/archives/2008/05/my-git-workflow

======
JeffJenkins
I've thought about using the index like that before, but the problem you run
into is if you decide you need to go back to, or even just look at, some
change several adds ago the data is gone. The index feels like I've just
copied some text in an editor: the more time that passes before I use it the
more likely I am to either have to check what is there or accidentally
overwrite it by copying something else.

My general philosophy right now is that I should only push one commit for each
complete feature or bug fix, which wasn't really reasonable in old VCS
systems. That lends itself to making micro-commits for almost anything and
then using rebase -i to clean up the mess into a single commit. I've recently
been experimenting with tagging the pre-rebase commit so that if I want to
look at the development history I still can. I use git-stash if I'm in the
middle of something and need to change branches for a few minutes, but aside
from speed there's no reason it couldn't be a commit as well.

------
DenisM
Is this article useful for someone who doesn't know git? It would be helpful
to have summaries/prerequisites as a first post... As is I can't bring myself
to read it.

~~~
bradx3
Not really. There are better git tutorials out there -
<http://osteele.com/del.icio.us/osteele/git> (from the article).

Git allows you to choose which way you work more than (say) subversion. This
article is an example of a slightly different way to work.

------
signa11
why not just use a separate branch for doing those experimental changes ? it
just seems too complicated.

