El 5/10/2007, a las 10:39, Paolo Ciarrocchi escribió:
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
-
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
