This article will introduce about reasons/advantages of git commits and the commit message convention you should follow and apply. Version control systems (VCS) are wisely used as repositories for the management of project code. While committing code to the repository developer has to write a commit message to express what has been add or change. Being a developer we have to write code, why we should care about this commit message? Is it worth investing in good commits?

Debugging

Git commits can help to understand what we were doing and give descriptive context when project teams check what has been added/changed. That is a useful way to share with colleagues for collaboration and feedback on coding.

By having a good descriptive commit message, we can easily use git blame to display the author metadata specific points in file history and get context as to who the last author was that modified the code line. This command can help to explore the history of a block code inside a file and can answer what, how, and why this code snippet was added to a repository. git blame is often used with a GUI display and below is a figure we use with the tool TortoiseGit

Giving a clear git commit message will lead to crucial debugging using git blame

git revert is another example of how good commits can help us. If each change is isolated, using git revert for just that specific commit to fixing a problem in production is perfect when a fast bug fix is critical.

Suggestion

There are a few points we can suggest on good writing commit messages

• When writing a commit message, make sure it well explains the reason for code changes to be added to the repository
• When making a commit message, consider if it can be amended with another commit or if this is an independent change that doesn't break the tests.
• Make sure to take your time to review merge requests so there are only good commits being merge into your code repository.

Good Convention

Having a standard is always everyone's wishes but the reality is not like that. Therefore, habit and practice are required in order to keep to standard work. There are some standard commits that are defined by the community and experts but still fail because of misunderstanding, communication, and lack of knowledge. The below standard will help you and your team to define a good commit message

• build: Build related dependencies changes (eg: adding external dependencies)
• chore: A code change that other users won't see (eg: change to .gitignore file)
• feat: A new feature
• fix: A bug fix
• docs: Documentation related changes
• refactor: Use this when there are semantic changes like renaming a variable/ function name
• perf: A code that improves performance
• style: A code that is related to styling
• test: Adding new test or making changes to existing test
• use imperative, present tense (eg: use "add" instead of "added" or "adds")
• don't use dot(.) at the end
• don't capitalize the first letter

I hope this blog can help you understand well the advantages of having standard good commit messages.

BUT PLEASE REMEMBER IT WILL NOT WORK IF YOU DON'T PRACTICE WITHOUT HABIT. 

THANK YOU!!!

Find Us @
Facebook
Telegram
Twitter
LinkedIn