I like this idea of using a standardized set of verbs at the start of a commit message.
My colleague pointed me to the Lean conventions, where they also include a scope. I find that redundant, because that information should be easy to deduce from the diff or just the paths in the diff.
I like the idea of adding the <type> at the beginning, particularly because of the benefits when bisecting. Pedantic me is slightly annoyed that feat (feature) is abbreviated but refactor isn’t - I guess it’s because people add features more often than they refactor?
the Lean conventions […] include a scope. I find that redundant, because that information should be easy to deduce from the diff or just the paths in the diff.
Their definition ‘module or directory name’ is a bit restrictive, but I want to interpret their ‘scope’ as meaning ‘concern’, which should after all correlate strongly with modules/directories. A commit log that starts every commit subject with a single-word description of the concern is pretty damn awesome to read.
Here is the commit log of a major project that uses this style: Mercurial’s history. Nice, no?
I agree that a concern tag like “py3” is useful. It is definitely not a verb.
I picked this practice up from another developer a few years ago and used it for a while. Its nice when you use git’s short log format to see if it is a [BUGFIX] or [CHANGE] or [FEATURE] but I found that the number of tags grow and morph over time into an unmaintainable mess when you bring in other developers. I think if you keep the list maintainable it can work well.
I don’t think you need standardized verbs as long as you use the the present imperative conjugation of whatever verb you’re using.
The machine readable semantics should probably be somewhere later in the commit message, like a “MODE=FIX” on a single line, and then have a commit hook that forces you to pick one in a template message.