Re: Question about "git commit -a"

From: Wincent Colaiuta <win@wincent.com>
Date: Oct 5, 2007, 10:48 UTC
Message-ID: <227149BF-1220-43F2-8B0B-B7E9FCA002B1@wincent.com>
In-Reply-To: <4d8e3fd30710050139j45a5a924t5c048994e3457c5f@mail.gmail.com>

El 5/10/2007, a las 10:39, Paolo Ciarrocchi escribió:

Show 13 quoted lines

> So you are used to do something like (please correct me if I'm wrong):
> - modify A
> - modify B
> - modify C
> - modify D
> - modify E
>
> $ git A B E
> $ git add A B E (A, B and E are now in the staging area)
> $ git commit -m "I just modified A,B and E"
> $ git C D
> $ git add C D (C and D are now in the staging area)
> $ git commit -m "I just modified C and D"

The conceptual shift is that in Git your index and not your working directory is your staging area, unlike (most/all?) other SCMs. If you fire up gitk and look at the development history of Git itself you'll see that it's one of the "cleanest" out there, and as you learn Git you learn about the various tools and tricks that it provides that makes it easier for a developer community to produce such a clean history; the index as a staging area is one of the key factors.

The basic workflow is:

   # work on a single change
   edit A
   git add A
   edit B
   git add B

   # see unrelated thing that needs to be fixed, but don't add  
(stage) it yet
   edit C

   # commit first change, then second one
   git commit -s
   git commit -s C

This is just one example of how having a staging area that you can control independently of your working tree can help you. There are other possible workflows and you discover them through use, but they all share the basic idea that you use the staging area to provide you with better control.

Sometimes you're trying to work on a single thing and you see a change within a single file that isn't related. In that case you have an even finer level of granularity available and can use "git add -- interactive" to add only specific hunks.

Finally, closely related to this idea of maintaining a clean history is the newly-added and wonderful "git stash". If you have a relatively complicated work in progress already half-staged in the index and you see something else relatively complicated that you want to attend to straight away then you can easily switch to the second task, commit it, and go back to the first task, thus keeping your development history nice and clean. This is a beautiful example of your SCM facilitating your work and making it easy rather than forcing you to jump through hoops. See the git-stash man page for more details.

I think all of this is incredibly powerful useful stuff, and all of it comes at a very low cost; it's easy to learn and doesn't require you to do any magical and complex history rewriting in order to get a nice clean history.

And on the subject of staging areas, thanks to "git commit --amend" you can even use the last commit as a kind of secondary, addditional staging area, providing you haven't published that commit yet. In other words, I frequently do:

   git show HEAD

Immediately after committing and if I don't like what I see I make modifications as necessary and do:

   git commit --amend

Cheers, Wincent