There is another good reason to break commits down into small "bricks" (as the author calls them) and that is bisect[1]. Up until very recently I only used a ti

There is another good reason to break commits down into small "bricks" (as the author calls them) and that is bisect[1]. Up until very recently I only used a tiny fraction of the git toolbox, but when I was complaining to a friend about how an app I was working on deployed fine on one machine but not on another with the exact same configuration he told me to run bisect. It took me a matter of minutes to zero in on the exact commit that broke the app on that one machine. This would have been something I would have spent hours, possibly days trying to figure out by going over every tiny config detail (it wasn't a config issue). Bisect is a powerful little tool to have in your back pocket when you know something you introduced at some time broke something and you need to find out what. The smaller and more "relevant" you keep your commits, the easier it will be to use. Obviously the opposite is true, if you have these massive commits which change large amounts of different files and/or multiple features, bisect becomes significantly less useful, almost worthless. [1] http://git-scm.com/docs/git-bisect http://git-scm.com/docs/git-bisect