Using git hooks can boost your productivity. Do more with less and improve your git skill set with this simple hook.

In my current development team we have some optimized flows and some others that can be improved. One of the things that I enjoy in our current flow is the fact that anyone can prepare a production release. We release code to production some days multiple times a day and everyone is comfortable to do it. As part of this production release we are expected to write the release notes, which can be tricky to track back if we haven’t worked directly on the ticket (either by developing it or reviewing the code). At some point it was suggested that we prefixed our commit messages with the ticket id. Everyone agreed but a few did not automate this process, keeping it manual. Naturally, it is a pain to remember to prefix our commit messages with the ticket id every time and once it becomes an effort, we easily discard the idea. Ultimately we want a effortless flow and add as little blockers as possible.

That being said, our release notes still need to follow a standardized format so they can be informative enough in case we have bugs or the client asks for it. Our release notes are relatively simple and recently I started pushing for a standard format for all the release notes. This means one markdown file with the following 3 headers: ‘Features’, ‘Fixes’ and ‘Internal Changes’. Within each of the groups we are supposed to reference the ticket id and title as well as link the PR that was opened with the changes made. Here you can see the contents of one of our release notes:

# Features

-   [Part 1 for Roles Audit Log]<link to ticket> - <link to pr>

# Fixes

-   [Campaign > Create > "Auto_enrol" is not saving correctly]<link to ticket> - <link to pr>

# Internal Changes

-   Upgraded to ruby 2.7 - <link to pr>
-   Added githooks configuration - <link to pr>

As I’ve mentioned before, if we have not been involved in all the features that are about to be released it is sometimes hard to link the information back. Usually most of the needed information is on the PR description, but once that it has been merged, the initial PR description is “lost”. In order to solve this, I proposed we relied on the combo: standard branch names + git hooks. Through this methodology we can rely on a git hook to prepare the commit message for us with a reference to the ticket we are working on.

E.g. for the branch name:

STAR-333-implement-amazing-code

whenever we run git commit -m "some message" the hook will prefix it with the reference to the ticket, as such:

[STAR-333] some message

What this hook is doing is parsing our branch name and look for a regex match to determine our ticket number. Based on that, if it finds a match, it prefixes our commit message with the ticket number unless the commit message already has one.

This assumes one has the git hook installed in the dev machine from which we are committing. Since workflow changes are usually a challenge and if people are not motivated to embrace this change they won’t, I also wanted to look for a solution that didn’t require much of developers time. This would be straightforward if the .git folder was committed to the remote repository but it isn’t, so I had to come up with another solution. In order to achieve that, I’ve prepared my hook file and stored it under .githooks directory, which I pushed to the remote. Alongside with this, I’ve written a simple Makefile that loops through the .githooks directory and creates symlinks under .git for each of the files in .githooks. With these two simple additions on our repository, as part of the instructions on how to setup the development environment, the developers are asked to run make, which will create the previously mentioned symlinks.

As I wrote before, the git hook pre commit prepare message needs to have a conventional branch name creation because we are using a regex to find the ticket reference. In order to do this in a comfortable way, I use a tool that I’ve written about before (and I’m also the maintainer of) called StoryBranch . Both the blog post or the readme of the gem should give you enough context on why I’ve built the tool and how I’m using it.

To summarize:

• We find important and valuable having a reference to the ticket on the commit messages. This can be a tedious task if done manually but it can be easily automated assuming we follow some conventions.
• A git hook combined with a standard branch name solves the issue.
• Git hooks can’t be added to the remote directly in the .git folder but they can be referenced using symlinks.

Both the git hook prepare-commit-message and the Makefile are available in gist