[allannienhuis]

This is one of the reasons I like to provide detailed commit messages, and encourage my team members to do the same. I treat the commit message like a short email to the team (even if that's only future me) about why and how I made the change. Summarizing the change in writing often uncovers logical flaws or missing edge cases. I've aborted my commit (after copying the notes for reference) more times than I'd like to admit when I've realized that I've not thoroughly tested something or missed updating that admin report that would be affected, etc. The act of 'telling someone' exercises different pathways in the brain and helps you think about the problem differently. As someone already pointed out - it's a flavour of rubber duck programming. It also works really well in a team environment where your CI system emails the whole team the commit notes. You get a low ceremony quick design review. "Did you update the X system/form/report when you changed Y?" replies happen more often than you think, and junior devs can actually learn a lot about an existing system just by seeing the approach used by other team members.

[tanzam75]

It's also a miniature version of literate programming. You can go through all the commits and get an explanation of how the program evolved -- not just the actual lines changed.