Feedback on this git commit message convention is welcome, and so are pull requests:

https://github.com/joelparkerhenderson/git_commit_message

I would recommend putting it in a git commit template if you haven't already. This will make it easier to implement the convention IMO.

Thank you for this!

This is a great idea. Interestingly, Google has a tool that will analyse your git history and identify "hotspots" i.e code that is regularly associated with commit messages with words like "fix".

I'm wondering if the same general idea is applicable to other types of commits given your list. For example, if you are regularly adding features and a certain part of the code base is touched, perhaps with a lower ratio of "refactor" commits, that code could be a solid candidate for refactoring.

Here's the tool i mentioned anyway https://google-engtools.blogspot.co.uk/2011/12/bug-predictio...

Not a bad idea actually. It's like the PowerShell 'approved verbs'. At first I was like 'meh' but after a while it makes sense as it greatly improves discoverability. Looking at a couple of repositories I contribute to this also looks close to what 'good' committers tend to use automatically.

I like all of these but am wondering what the following two mean.

Start = Begin doing something; e.g. create a feature flag.

Stop = End doing something; e.g. remove a feature flag.

Could someone explain these and give a few examples?

The current buzzword for feature flags is 'branch by abstraction'.

The idea is that instead of making a version control branch to change feature A to feature B and then merging back into the mainline of development, you build an abstraction over the thing you want to change, build a new implementation of that abstraction, switch out the two and then (if you like) remove the abstraction, all within the main line of development.

So instead of history that looks like this:

    *    Merge branch 'feature-cookie-login' into master
    |\
    | *  Polish up cookie feature
    | |
    . *  Switch from tokens to cookies
    . |
    . *  Clean up and refactor login code
    |/
    .
    .
    .

Your history looks like this:

    * Stop abstracting the authentication type.
    |
    * Switch from auth tokens to session cookies
    |
    * Add a SessionCookie authentication type.
    |
    * Start abstracting the authentication tokens as a generic authentication type
    |
    .
    .
    .

But with any completely arbitrary commits interspersed between those commits, as none of them break other code. The first one creates an interface, the second one reimplements the interface, the third switches the used implementation and the optional fourth removes the abstraction and deletes the old implementation.

Thanks.

The idea is usually to allow committing partially completed or deployed features, which are hidden by config flags until you're ready to activate them. When the feature is fully baked and effectively always on in production, you just remove the flag to make it permanent.

Using feature flags can increase a team's productivity by encouraging multiple commits a day, every day. It can also make rollbacks faster.

For my personal projects I often commit unfinished stuff. Using the kinds of flags you describe sounds like a good idea for projects where more people are involved indeed. Thanks.

well, it works for anything that you deploy often. some features are just big, and you don't want to have something sitting there undeployed for weeks. it helps to have bigger teams, because merging and deploying often is obviously good, but merging and deploying often help to make sure your individual parts don't slow anything down/etc, especially if the feature isn't self contained

I particularly like this because it doesn't interfere with the flow of the commit message's first line in explaining what it does. There are too many commits out there that waste half the first line with the ticket number, area of code, etc.

Instead of 'JAT-1241: app/index.js(opt): Optimised the index', 'Optimised the index' should be fine. Tools can understand that, and can already work out which files changed.

This is great

Some of the active verbs are also commands that automatically close/reference issues right out of the box on GitHub & BitBucket (& I'm sure on GitLab too)

This is a really nice way doing commits. It's the kind of simplicity that can be made into a simple document and shared easily, or printed out and put somewhere everyone can see.

Might try and get my team into using this.

At the moment our teams commit messages are a mangled mess of everyone's own 'commit language'. It can be really tricky to quickly scan over commit logs and get a feel of where development has been heading over the last x weeks.

I use similar strategy with my team. In addition I ask them to summarize in one line the job they are going to do before starting the job... which is related to the task description in the task board. That is normally the commit message. Works (most of the time...).

How do you enforce such commits messages? People makes mistakes, or forget stuff. But when you have a pull request, all intermediate commits are already pushed to central repository. They already are public. You can't change them anymore. Pre-commit hook?

The commit-msg hook. You can use it to validate your project state or commit message before allowing a commit to go through. The git docs demonstrate using this hook to check that your commit message is conformant to a required pattern.

It's not easy to enforce local hooks. And maintaining it becomes difficult if you have a lot of small repos.

Great idea, I'm gonna steal this.

conventions on commit messages can turn the git log to a good project's story, take a look at "Angular vs React : text analysis of commit messages" for the example https://medium.com/@sAbakumoff/angular-vs-react-text-analysi...

That's a nice way to standardize. I like it.

Useful; never actually thought about using ubiquitous language here, but it makes absolute sense.