The Commit Message Standard

hello@mikebell.io (Mike Bell) — Thu, 03 Apr 2014 00:00:00 +0000

Since we have git flow as a nice standard it makes sense to standardise our commit messages as well.

Here’s the following proposed standard:

[Updated | Added | Removed (required)] [Component (required)] [Reason] - [Issue Reference (required)]

Action - Updated/Added/Removed - Three options to concisely describe what this commit achieves. If your commit message doesn’t fit any of the words then you might want to reconsider splitting the commit up into smaller chunks (git add -p). Other verbs can be used here but sticking to these 3 as a standard makes you think a bit more carefully about the context of the commit message.

Component - The area/module/class/method you’ve edited. Note that this isn’t filename it’s a reference to the general area so if people are searching for commits related to the area they can find it easier.

Reason - A general reason for the update, at a minimum it should include a one line summary of the issue your references.

Issue Reference - A mandatory reference to the ticket ID.

I’m looking for feedback on this so please post a comment below!

Additional Resources:

@miss_jwo pointed me to https://gist.github.com/rmccue/daf72eaffe984f988a0a - Some good starting points but I think it misses a lot of vital points.

Thanks for reading via RSS!

Send me a message on Mastodon or email me

Git just fucking get on with it.

hello@mikebell.io (Mike Bell) — Tue, 16 Jul 2013 00:00:00 +0000

Here is an unedited version of the post. Raw and uncensored:

After many a fruitless and frustrating discussions around git best practices here’s my bulletproof method:

Tag it - if you want to release code you have to tag it. By tagging you also own that release if it doesn’t fucking work I’ll hunt you down. You did test it, right?
What branch should I use? I don’t give a shit. I really don’t, you’re a big boy now we’ve let you use big boy tools like the command line take some initiative.
It’s 5pm on a Friday before a bank holiday can we release? Wait there’s a gif for this…

OK so it’s extreme so here’s the rational slightly less angry and more rational version:

Tagging - By tagging you recognise that the build is ready for production, it’s a releasable point in the code. You’re also taking responsibility for that release (you may not be release manager), you’ve deemed it good enough to release to production.
Branching - Seriously here I don’t care, ideally you’ll be using your own fork of the repo so you can do whatever you want (if not create a new branch don’t touch dev/prod). That’s the great thing about git if you want n branches you can have n branches. Just make sure when you’re ready to merge back into the production repo you submit a pull request against my dev branch.
No brainer here, unless it’s an emergency your code release really isn’t as important as you think it is. There is also a flip side to this, if your test coverage is pretty damned good then fine release, the release has to be pretty tight though.

My ideal repository would be two branches, dev and prod. People submit pull requests to dev and I then merge code ready for release to prod and tag it ready for it to be released. It’s simple, here’s an interesting use case:

Company A readies a release tagged 1.0

Company B has an emergency release that has to be deployed

Company A doesn’t want to mess around with their branch

Company B branch from 0.9 applies any emergency fixes and create 1.0.1

Company A merges in 1.0.1 changes from B and creates new release 1.0.2

There are no reverts here, no backwards and forwards between companies asking wtf is going on. Just a simple logical solution.

I hope this helps people refine their git practices.

Thanks for reading via RSS!

Send me a message on Mastodon or email me

Git on Mike Bell - Blog & Stuff

The Commit Message Standard

Git just fucking get on with it.