You prepare to commit your files, having made sure that all the right changes are in, that they belong to one logical change, and that you have the id of the task that they belong to. Your editor opens up and you see those familiar commit message instructions, but wait! You suddenly remember that you should start your commit with the id of the task prepended with a # character, but that would lead git to think that that line is a comment.
How do we solve this?
Easy! We simply tell git not to use the # character for comments, but pick a different character instead.
In short
There’s two ways to do it, both producing the same result. You can either run a command from the command line or edit your git config directly. In this case, imagine we want to use a semicolon (;).
Command line:
git config --local core.commentChar ';'
Directly modifying your git config file:
[core]
commentChar = ";"
Motivation
So why might you want to do this? As mentioned in the introduction, maybe your team has a standard format for commit messages, where each commit should lead with the id of the task that the commit relates to.
We use GitLab at work, where if you put a number after a # in your commit message, it will create a link to the issue with that id, which also adds an entry to the history of said issue. In addition to this, if all commits are prefaced with the task id, it becomes very easy to find out what task a commit relates to when looking at the history.
What might go wrong?
This is such a simple modification that there’s not much you need to be aware of, but if you try and use a comment character consisting of more than one character, git will fail when you try and invoke a command:
error: core.commentChar should only be one character
fatal: bad config variable 'core.commentchar' in file '.git/config' at line 6
Finishing thoughts
It’s a simple thing, but it’s one of those things that improves your life just that little bit. You can even combine it with the custom config we mentioned last time to have this apply to all repos in your work directory, new and old.
Now as a final thought, what should you pick as a comment character? It’s really up to what you need for your specific use case, but I find that ; is very rarely something that you’ll want to start your sentences with, so that’s my go-to.
Latest comments (1)
Man, I'd rather the standard format change to require
feat:
bug:
Etc. I understand changing standards sucks, but having a standard that conflicts with the tool standard sucks as well.