A Guide to writing Industry Standard Git Commit Message

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.