Reason 1: keeping codebases cleaner. By keeping commits larger-grained (especially if I'm deleting a functional component), it supports deleting with abandon,

Reason 1: keeping codebases cleaner. By keeping commits larger-grained (especially if I'm deleting a functional component), it supports deleting with abandon, and follow the "you aren't going to need it" (YAGNI) principle, rather than having large commented-out sections (or worse, large sections of deadwood in your tree). It also allows you to restore it later if you need it again by only reverting one commit. Reason 2: finding out WTH went wrong. By having a master/stable branch and a development branch, if anything goes wrong, I can always diff between the branches to see what/how things broke. Sometimes it's a change to a dependency. Sometimes (ok, most of the time) it's a change I made. This said, I think it's useful to me because I know what's in the history already. I think looking through commits from someone else with a tree that I'm not familiar with is going to be of very limited use, especially because people don't generally provide the critical answer of "why" a change was done in the commit log. Related #protip: always try to describe why you're making a change in the commit log. The how of the change is already there: it's the diff. Why you're either making the change or choosing a specific method over another can be invaluable to the Engineers of Tomorrow, and prevent them from a regression due to context loss/tribal knowledge loss.