Commit message formatting conventions

[dextermb]

What you would like to change/add

I'd like to see standardization in commit message formatting.

Why you would like to change/add this

Currently our commit messages range from being descriptive enough, overly descriptive and not descriptive at all. There are many different standards for how commit messages should be formatted and all should be explored and discussed.

Examples

As described by conventional commits, their format is as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer]

For example:

feat(lang): add polish language

or

fix: correct minor typos in code

see the issue for details on the typos fixed

closes issue #12

This is similar to what I've seen from the likes of Yargs (node CLI framework) and Electron (JavaScript based applications).

What other conventions have you seen and liked? And what did you dislike?

Checklist

• [x] I have checked that this is not a duplicate issue.

Sources

• conventionalcommits.org

[robmilward]

I feel like this restriction would just mean I commit far less often than I do, as I generally commit small chunks of work that I wouldn't individually describe as a feature, or fix, but only when considering the branch as a whole.

Unless the idea is to mark the commit as a feature even if it's not the full implementation?

[dextermb]

I feel like this restriction would just mean I commit far less often than I do

I tend to commit in decent chunks rather than each small change or progression towards a feature/fix. I definitely see where you're coming from though.

Unless the idea is to mark the commit as a feature even if it's not the full implementation?

Not sure, this is an open discussion. I'd say you would tag it as a feature an in the description describe that it's not complete?

[AlexCatch]

I don't think having a strict format is the way to go - I think just asking devs to write meaningful commits is enough.

[dextermb]

I don't think having a strict format is the way to go - I think just asking devs to write meaningful commits is enough.

I'm good with that too, what would you define as meaningful?

[AlexCatch]

Just a decent description of what the commit contains - no need for a strict definition, you'll know if you've written too much or not enough.

[dextermb]

Just a decent description of what the commit contains

I agree with this.

you'll know if you've written too much or not enough.

In the past, here, I've seen like 100+ characters in the first line of a commit message. That's way too long. Perhaps short and to the point descriptions.

If a longer description is required then use a new line. Such as the 50/72 rule.

[AlexCatch]

Most git clients these days have a summary and another box for a description where longer descriptions can be entered.

[dextermb]

Most git clients these days have a summary and another box for a description where longer descriptions can be entered.

👍 Definitely, such as GitKraken or Sublime Merge. Guess people will have to start using the description box