On my team of 5 coders, we've traditionally adhered to a common git commit message standard stating (only) two rules: commit messages should include the why rather than just the what and they should be written in the past tense.This is quite loose (e.g., some people prefer writing longer messages, some write shorter ones; some add a trailing period, some do not), and that's okay - I don't think that kind of heterogenity has caused any harm so far. Our main use cases for the commit messages - code reviews and researching the reasons for certain changes or code constructs - are working well.Recently, one of the team members has expressed a desire to follow the Git repository style, which is becoming a best practice and mandates writing commit messages in present tense, imperative mood, thus contradicting our rules. The rest of the team want to keep using the past tense style, as the imperative style feels unnatural to them.As the team lead, I'm now wondering, how far does the need for consistency in commit messages go? Is it important that all team members use the same time and mood? What are the arguments against letting some use one style, some the other?
Is it important to have a consistent commit message style on a team?
version control;coding style;git;coding standards
Grammatical items such as tense or mood aren't usually important beyond that the message should make sense and be understandable by the team. Making a lot of rules about how to phrase the free-form part of a commit message is probably a sign that the wrong things are being concentrated on.More important would be consistency in specific syntactic items. For example if you have a ticketing system, having all commits that relate to a ticket have the ticket number in the same place using the same format.