Which tense to Use while committing messages on GitHub

Basically, the schools of thoughts are:

Imperative (a.k.a. present tense)

• Should read like:Make foo do something
• Git uses the same imperative style and it shows when you do merges with commit messages: Merge pull request #666 in kek from lord
• It tells someone what applying that commit will do, so it should read something like If I apply this commit, it will [make foo do something...]
• More concise

Past tense

• Should read like: Made foo do something
• People reading the history tend to think of it in past tense…because HISTORY
• Reads more like a diary: Last <insert date here>, I made foo do something....
• Saving a couple of characters doesn’t matter much as long as it’s still easy to read

The list goes on and on and the debates tend to go on forever, but I for one have seen both sides. I think it really depends on team preference — there is no right or wrong answer here. What matters is consistency. The team should agree on a convention and stick to it.

Personally though, I still think that it should be in the past tense. I have been using it for almost (if not) a decade and the only times I look at commit messages are:

• trying to find out what was being done in that particular instance (via git blame)
• evaluating the thought process / skills of an applicant using git (see if they do atomic commits, squashes, etc.)
• checking what other files were touched in the commit

In all three cases, I read the commit messages as diary entries. I don’t think of it as a ‘If I apply this commit…’ thing mainly because one, I don’t have any plans on applying the commits one by one (we have git clone for a reason) and two, I am looking at past work, not future / present work.

Now one can argue about work being present work so it should be the present tense. Sure — but the fact that it has been saved in git, and it has been logged means it was done. Done = past for me.

Again, these are just my own personal reasons and preferences and it will always boil down to team preference.