Ever since reading that post, I've tried my best to adhere to similar guidelines. On a personal level, it kind of gives you a little 'retro' on what is was you just did, which is never a bad thing. I've also found myself making larger, more meaningful commits, which, I think, is a good thing.
Agreed. I've found that for me, to have meaningful commit messages, you have to have a meaningful amount of work complete. Otherwise you end up with a bunch of "more work on feature x" messages.
This is counter to a lot of the "commit often" mantra that so many git people have, but it's working better for me.
"commit often" is fine. It's "push often" that gets you into trouble. With an interactive rebase, you can polish up your commits and their messages before pushing them, presenting to your peers a finely crafted (readable, reviewable, maintainable) publication.
Indeed, I only discovered that recently and it makes git pretty cool.
It has the added advantage of being able to merge commits that fix intermediate bugs that you introduced yourself and fixed immediately. There is no reason to bore other people with those.
Commit often, fix them up. This is why I just can't side with the people who claim rebasing and rewriting your personal history is some sort of affront against nature. Take their argument and add it to the need for useful commits and what it unpacks to is that you should forgo all use of your source control until you have created a Perfect Patch, at which you are finally allowed to commit, until you create the next Perfect Patch. Of course that's not how they see it but it is what it actually translates to, inescapably. Really misses the point of the whole thing if you ask me; it really feels like accidentally raising old hacks to best practices.
