Introduction
In the realm of collaborative coding, the harmony of a team lies not only in the lines of code but in the consistency of communication. Git commit messages, often the unsung heroes of version control, play a pivotal role in understanding the evolution of a codebase. Ensuring these messages follow a unified structure can be a game-changer for teams striving for coherence and clarity. Moreover, standardized commit messages become crucial, as they might be parsed to comply with company standards, transcending mere organization to align with broader corporate requirements. This blog explores the power of Git commit templates in fostering a shared language within a team, ensuring compliance with both internal standards and the facilitation of a seamless understanding of the project's development history.
Context
I've encountered numerous instances where I've overlooked the prescribed company standard for commit messages. In the rush of coding and the flurry of changes, omitting something as minor as a semicolon or missing a specific format happens all too easily. It's these moments that disrupt the flow, sending me on a scavenger hunt through documents or repositories to retrieve the correct format. The process of fixing the commit message, pushing with force, and rectifying the error becomes a detour, stealing both time and focus from the actual task at hand. These interruptions, seemingly small, can snowball into significant distractions, impeding productivity and the seamless progression of work.
Steps
To overcome this hiccup I deciced to step my git skills a little bit up and decide to set my pre-commit-msg with a template that will just print for me how the standard commit message should be with a brief explanation of every section.
For example, I created a .gitmessage within my dotfiles folder and created a link for it to be at home folder as well.
Then I just ran git config --global commit.template ~/.gitmessage
This makes this template default for all repositories for my user. That's not a problem for me as this machine I use only to code for my employee that uses same standard between every project.
It's possible to create a definition for each project but this is out of scope for this post. But I bet it's just a matter to create a local hook inside the project folder.
My .gitmessage looks like this:
#Mandatory Format:
#GITHUBID: [TYPE] MESSAGE
#
#TYPE : Is one of the following:
# feat : new feature
# fix : bug fix
#GITHUBID : GITHUB issue ID.
#MESSAGE : Brief description of the change.
Result
Now everytime I do a git commit it will write my chosen template message below where I should write my actual commit message.
#Mandatory Format:
#GITHUBID: [TYPE] MESSAGE
#
#TYPE : Is one of the following:
# feat : new feature
# fix : bug fix
#GITHUBID : GITHUB issue ID.
#MESSAGE : Brief description of the change.
Future improvements
With this I can only have the template easily at my screen exactly when I need it so I can't forget about it. However I still need to look some info outside, for example my Github Issue ID.
One idea for the future is to just have this Issue ID while I create my new branch or something like that. Then I can parse that using an local environment variable or something like that. I will probably need another hook for changing branches.
I saw some solutions that creates working branch with issue ID already and then just parses it when committing. Personally I don't like this idea because I like to have my branches with actual meaningful titles so I don't have to open github to know what they were.
Top comments (0)