When I'm ready to commit and my change is more than couple of lines of code in one file, I do
$ git add --patch .
Then git nicely shows me every hunk of change I made in the code.
I see two benefits of working that way:
- Obviously it is opportunity to skim through my own code, and it leads to more focused reviews than if I just read through whole source, or even skim through full patch to be committed.
- It leads to atomic commits which I'm big fan of:
- I don't forget to add things to index. This is not much important when using git, 'cause I always can amend my commits, or even rebase interactively, but it's always nice to form nice commit earlier rather than later. Of course I can do just 'git add .' or even 'git commit -a' for that which leads to next point:
- if for some reason I made several unrelated changes, I have an opportunity to split my change into several logical changes if needed. That is where real power comes.
$ <hack hack hack>
$ git add --patch . # interactive session where I select what comes to commit
$ git stash save --keep-index # I stash my unstaged index; needed for the next step:
$ <compile and run tests to make sure you haven't screw with partial adding patches>
$ git commit
$ git stash pop # get the remainder of my changes back in working copy$ <repeat with git add>
If I have screw somewhere:
$ git reset # moves staged changes from index (they are still in working copy)
If I want to review the changes one more time after adding but before commit:
$ git diff --staged
It sound like a lot of work should be done for every commit. I don't know. First of all I do it fast enough (shell history can help do it even faster). And I use this technique only if I've touched code in several places.
Advanced techniques and details of git add you can add in the documentation, and in Markus Prinz'es article.