[zoomablemind]

Commit messages are just that - an additional communication tool. As long as any format helps keep the understanding within a team clear with a minimum of overhead, so be it.

After all the commit message is secondary to the actual code committed.

I'm sure everyone can share an episode when a nicely worded commit had to be followed up with an ugly 'Fix a typo' message.

The most practical convention is the one that's automated to some degree, for example, issue/feature tag auto-linking or some template driven messages. Either way the message should not become an ultimate hoop to jump before the actual commit and one more thing to 'maintain', the code should be the focus.

In my experience, a commit message describing the committed behavior (even when intended) helps tie the code to the overall scope. In case when it's a bugfix, it still must be tied to a correct expected behavior.

So in some sense a commit message could serve as an auxilliary level of unit testing. Of course, I'd rather put an effort to enforce the actual practice of unit testing over structuring the commit messages.

[pantalaimon]

> I'm sure everyone can share an episode when a nicely worded commit had to be followed up with an ugly 'Fix a typo' message.

There is `git commit --fixup` and `git rebase -i --autosquash` for that ;)