I bumped into an article a few days ago. It was short and simple, related enough to make me wonder if we have the same thing in the team. How a git commit message should look like.
The blog post states out what a typical git commit message looks like
- type: stands for the main action
- scope: stands for the codebase section
- subject: short description on the commit
type should follow some key actions: such as
refactor, ...etc.; while
subject are optional.
But how optional? My question exactly.
We're currently using Outline as the knowledge hub, where every piece of accumulated processes, workflows, document material are stored. I did a round check just to realize we haven't had any notes on the git commit-msg convention.
Working in an IT woodland, GitHub and Git commit -m isn't a new thing, but I never heard of any 'convention.' In fact, I didn't know we should. And therefore, I tend to make it with a text, randomly noting down the action I did. For example, if I were writing a new blog post, my commit-msg would likely be
Since I've mentioned we weren't forced to follow any convention. Sometimes my message would be
I pinged a teammate. He's one of the Frontend seniors on the team. As he explained how commit messages convention works in the team, it strikes me that we, in fact, do have a convention. It's based on the type of commit that we're working on.
Each project has its different commits. The commit either affects one part of the project (this is where we use
scope), or affect the whole project (where
scope is unnecessary)
Examples for 2 scenarios:
- type: fix
- scope: foundation
- subject: ordered list doesn’t show numbers
- type: chore
- subject: upgrade tailwind and twin.macro
We have a playbook - our guides on getting things done. Here's the old flow we have on git commit message.
and I think it's time to update a new version. Check out our latest update at dwarvesf/playbook/write-a-good-commit-message
Subscribe for “The Next Bytes” where Han & the crew draft up our observation in the industry.