I do want to add something that I haven't read in this thread yet (or may have missed), since I explained it in a similar manner to a colleague today.

When working on personal projects, we honestly don't have anyone to deal with other than our own multiple personalities (who can, honestly, be complete schmucks that often forget the purpose of how or why something's been done.)

We don't just push to master. We represent and act as the almighty Master of the Project.

However... when working with a team, which should gently force a compliant adaptability in your habits, that change hasn't been applied yet. The commit you just pushed, won't be (and shouldn't be) directly to origin/master, or simply merged by yourself at the end of the day.

That commit has only been proposed, and - at this is point - it has nothing to do with what you've done, but needs to describe briefly what it will do if merged to master.

This is also why commits shouldn't be a day, or even an hours worth of work. They should be individual changes, responsible for what you're proposing it should do.

Now... why they call it a 'log' - which is defined as a record of past events, now giving what seems to be commands being yelled at the wall - that's a whole other issue.

Always imperative. Mostly because that's how I learned Git from a Udacity course. It made a lot of sense as you're instructing the codebase rather than just writing what you did.

As suggested here chris.beams.io/posts/git-commit I write the subject so it completes the sentence "If applied, this commit will <commit subject>."

Use the tense that explains what's being done. It's not fun but that's a sign that there's work to be done.

If it's NEW functionality, then use the imperative. If you CHANGED functionality then use the declarative.

Just use the grammatical rules of ENGLISH -- specifically tense -- so in that way you can be sure that it all makes sense.

-- edit -- and apparently I've been watching way too much ERB and PRB on Youtube.

Imperative mood for teams, and past tense for personal projects (because I enjoy talking to myself.) :P

Just whatever the local code conventions say, if I can remember. I don't have an opinion of my own, it seems inconsequential.

My first commit messages were in past tense, but slowly I moved to imperative. I was greatly influenced by Chris Beam's article How to write a Git commit message and I just can't recommend it enough. I will share a passage of the article:

The imperative can sound a little rude; that’s why we don’t often use it. But it’s perfect for Git commit subject lines. One reason for this is that Git itself uses the imperative whenever it creates a commit on your behalf.

That being said, I still find the past tense acceptable for commit messages. At the end, it's the message that is most important, while the words are just the means by which you express it.

I created a system to includein the git message log, using single line statements and custom identifiers.
These go at the start of a new line:

1. ~ is used for if anything has been changed, such as refactoring or fixed a bug
2. - is used for the removal of methods, variables and functions (not files as thats present in the git history anyway)
3. + is used for the added of methods, variables and functions (not files as thats present in the git history anyway)

I am for the imperative although I wouldn't necessary call it imperative but more 'what does the commit do' VS 'what did the developer do' :)