I don't really get people using git commit -m. I never do that. I always use just git commit and write my commit messages in vim that opens up in the same terminal.
First of all, it allows you to easily write extended commit messages (just leave the second line blank and start writing the extended message on the third line). A good idea would be to leave (#more) anchor at the end of the first line, so that others would know there's actually some more info they might want to read.
Then you can always see the files currently being committed while you're in the editor, that's convenient. Last but not least - it helps me take my commit messages seriously.
I commit pretty frequently, so unless I'm merging in a large feature I tend to use git -m more often.
That doesn't mean that I don't rebase a bunch of those smaller changes away before pushing them upstream it just means a lot of the changes I commit are small enough that it's easier not to load Vim to write a commit message.
I actually enjoy witty and clever commit messages. Just the other day one of my coworkers really enjoyed a commit message where I wrote "upgrayedd" instead of "upgrade".
No, it was pretty spontaneous, as the particular individual who typically works with me on that project and I were having a conversation about Idiocracy just hours prior to that.
I feel like a better approach for that sort of solution would be to use a hash-tag based (#) tagging system. English has so many tenses and people mis-spell things anyways that basing your search purely off of the text of the commit message is always going to be tricky. Anyways, the point of the commit message is that it be human readable, not machine readable.
Personally, I like clever commit messages. They remind me that the project was written by humans for humans.
Also for more severe rewriting of the history check out "git rebase -i <base commit>". You'll be shown a list of commits between the base commit and the HEAD in your editor. From here you can rearrange and delete commits, and mark them for editing and squashing.
I use this all the time for cleaning up topic branches before I push them out.
git commit --amend is also useful for when you immediately realise that you aren't happy with the commit message (it has a typo in it, or you forgot to mention something), as you can use it without git add -ing anything, just to edit the message.
A quick note about amend, if you git push before you amend your commit, when you try to push the amended commit, you'll get an error about non-fast-forward references. If you're sure that nobody has grabbed your commit since you've pushed it, you can just git push -f, and it'll replace your original commit with the amended one.
I sometimes use --amend, but it's good to get yourself into the habit of just making a new commit, then squashing it with git rebase -i.
I use magit.el for Emacs which makes this really easy, and if you screw up getting your data back from the reflog is a lot easier than if you just had a bunch of --amend fixups.
I don't always commit as often as I should, but ever since reading Ryan Tomayko's "The thing about git"[1], I use git add --patch/-p to solve the problem of overlarge or mixed commits. It allows you to snip out pieces of the changed files to add, rather than adding the entire file at once. (Perhaps everyone already knows this, but I used git for months without knowing it. So maybe I'll save someone else.)
Seriously. Just commit one thing at a time. Don’t wait until you go home, don’t fix three really simple bugs before committing, commit every single change separately.
This is important. Nothing fills me with dread like a commit message that says "fixed NullPointerException in renderer (also a few whitespace changes)".
Email subject lines are by convention a short explanation of the message. Commit messages, regardless of the SCM, should be the same. The difference with git, and what I inferred from this article, is that commit messages should be verbose. It should be a way for someone to figure out that "bug #33423 has been fixed. Opening files now executes in the proper thread." for a very short message that gets the point across.
If one doesn't have bug tracking software to go to and read about why the commit was done, then it should be much more verbose: "Opening files on a select box executed in the wrong thread. Looks like it erred during startup, where we can't yet fork the process. This patch mitigates the selection box during startup by checking to see if we can fork into our proper thread or not. If we can't, we wait until it becomes available."
There is no reason a commit message cannot be a novel unto itself. And something like that will require a period at the end. If you're trying to limit yourself to a single sentence, or something that can be fit into a tweet, you're only hurting yourself.
First of all, it allows you to easily write extended commit messages (just leave the second line blank and start writing the extended message on the third line). A good idea would be to leave (#more) anchor at the end of the first line, so that others would know there's actually some more info they might want to read.
Then you can always see the files currently being committed while you're in the editor, that's convenient. Last but not least - it helps me take my commit messages seriously.