Segun Tuase

Posted on May 23, 2022 • Edited on May 25, 2022

A Guide to writing Industry Standard Git Commit Message

#github #git #programming #opensource

I bet you already heard something about Git before starting this article whatever led you here, you’re welcome and I hope you find the solutions.

Brief Explanation of Git

We have large projects that need contribution, Git simply helps developers manage the different contributions and bonds them into one unit. It also helps in controlling the versions of the projects which is version control, this is a dummy definition but it’s the best way I could explain Git.

A standard meaning of Git is that it’s a DevOps tool used for managing source code. It is a free and open-source version control system used to handle small to very large projects efficiently.

Before proceeding, I advise you understand a bit of git workflow Here

Git commits

Git commits are a snapshot of the codebase or project's current stage/state. It allows the system to store the staged changes.
Commits are used as a timeline for the project’s contribution and changes, It also helps in defining milestones in the project. Commits can also be used to track the team’s productivity and KPIs.

Industry Standard Git commits

I choose to describe this as Git commits that can be generally understood across the tech ecosystem. It shouldn’t commit messages that have very complex terms, it should be readable and understood by people that don’t even contribute to the code base.

The necessity of Industry-standard commits

Now, the necessity of this is to make your commit messages specific to your committed code even if you look back at the code you should be able to understand the change you made via the commit message. It also helps new contributors understand the commits and changes made. You could know why a person made this commit and the effects it would make if you change that particular line of code.

Your commit message should be:

Understandable
Enough
Unambiguous

Before coming up with a commit message you should consider:

Why did I add this commit
What changes does this commit make
Are the changes necessary
Do the changes solve any ticket or do they refer to any external links or part of the code

The Industry standard commit message method we will be checking out is the

<type>[optional scope]: <description>

[optional body]

[optional footer]

Different standard commit types we can look into:

fix: This is to commit a resolved bug in the codebase

feat: This is to commit a new feature to the code base

chore: This commits changes that are not related to a feature or a bug it involves modification or updating dependencies

refactor - this commits changes that involve refactored code, that includes refactored code or changes

docs - This commits changes made on the documentation, readme.md or markdown files

style - This involves style changes in the codebase

test - This commits changes made in the test file including corrections made

perf - This commits to improve the app's performances

ci - This commits make changes in the CI integration like the files and scripts

build - These are files that involve the build files and blue dependency

revert - This commit signifies reverting to a previous commit

An example of this is

feat: Add withdrawal button on home page

You could also add standard commits with their emojis different commit types have different emojis like
fix: Fixed the contact form
Read more about that here

Conclusion:

The skill learned in this writing will improve you and make your codebase more organised. It is necessary to document your processes and track your changes.

When your code becomes legacy code and a new developer has to work on it your commit message has made it way easier for the incoming developer to work in your codebase even in your absence.

If you have suggestions on how to improve commits you could suggest them below.

I really hope we have all learnt something from this article on improving our git commit messages.

Latest comments (28)

Robert Bornschein • May 30 '22

More people need to know this.

Bruno • May 27 '22

Thanks for the post

Aarav Reddy • May 27 '22

Nice work

Segun Tuase • Jun 4 '22

Thanks

Zoller • May 26 '22

Actually despite this is a good writing, a lot of cases restrit you from using it. Like big companies, where the ticket numbers are a must to include, or other restrictions. In the other hand, a lot of big companies does not give a fork about git commits, when I worked for Bl*kR*k, they only used master branch for all ther codes pushing from the office located in Delhi and they were just looking at us, why do we want to use several branches for our work to commit? I was frankly stunned... For another company I am actually working now only I am using proper git commits and I always see the backend developer pushing commit with messages like "trying again" and "try #68", "third time the charm", etc... I am really enjoying using proper commit messages, I also created some scripts which creates a release documentation with all the commits between last and recent releases with ticket numbers, descriptions, and changes as countes integers. But as I already said, majority of IT does not think about this as an important thing. But in fact it is.

Sophia Nelson • May 25 '22

Thanks for this.

Ambriel Goshi • May 25 '22

Thanks for writing this.

Philip Damra • May 25 '22

There's actually a specification that covers this topic called Conventional Commits: conventionalcommits.org/en/v1.0.0/

Segun Tuase • May 25 '22

Yes, I used this when writing the article. Thanks for sharing.

Julien Barbay • May 30 '22

you should at least mention them in your article. without this, it sounds like a huge uninformed rip-off rather than an explanation of it.

Kelvin Onuchukwu • May 25 '22

What prefix would be best to use when you're making an update to a feature?
Let's assume you've already added the feature and you're now making an update to it, should you use chore or "update"?

Lars Gyrup Brink Nielsen • May 29 '22

"refactor" changes the implementation of existing functionality. No observable change from the user's perspective.

"feat" can add a new feature or introduce breaking changes to existing functionality. Add "BREAKING CHANGES:" to the commit body or an exclamation point to the commit type, for example "feat!: make name parameter mandatory" for an API.