Don't rely solely on your code base's latest snapshot. Rely on its history.

This is also another benefit of having an organized code-review system that records review comments perpetually. Oftentimes, I'll wonder why someone's using an obviously short-sighted and naive algorithm, only to look through the review comments and see the original author say "I know this is a bit of a hack, but it gets the job done now, we've got to check this in in the next two hours, and we can fix it later." Or I'll do the same and see, "I tried this elegant solution, but it doesn't work for reasons X, Y, and Z", saving me many hours of going down a blind alley.<p>It's generally good software engineering practice to build for your needs <i>now</i> and not worry too much about anticipating your needs later. Code reviews naturally end up surfacing lots of concerns of the form "But what happens if the system changes in this way later?" If you have a record of that, then when the system actually <i>does</i> change that way later, you can refer back to what the issues were and what potential solutions the original designers had in mind.

&#62; never write a commit message without the diff in hand<p>To do this in git, use the --verbose flag with git commit. I use it in my configuration by default, and it really helps.

Comments with every commit are definitely important and helpful. And they have to be done while looking at the diff. The practice of reviewing and commenting diff not only helps in future maintenance, it also has immediate benefit -- help to identify bugs and silly mistakes in current commit. I don't use Git though -- I use Subversion.