How to write Good Commit messages

Writing Good Commit Messages is at the core (heart) of Programming along side Good Comments and Readme file.

Have you ever wondered how you can improve your Git commit messages? This article outlines practical steps to improve your commit messages to the next professional Level.

This article assumes you already the basic knowledge of how Git works. If not, I would suggest going through the Git Handbook.

Why should you write Good Commit messages?
Have you ever gone through your previous project and wondered what does this cold do or what did this fix do? If not, I would suggest you take some time to look at your previous projects, run “git log” to view Previous commits.

So what is the secret that makes Open source Projects different?

What Makes a Good Commit Message

1. Clarity
2. Brevity
3. Consistency

Giving your Best Bid

Writing Good commits Messages is like writing a message for your future self. Writing Good commit messages also aids Good communication (The sole aim of programming — Writing for Humans First before Computers) when working on a team Project.

Writing a Basic Commit message

Basic: git commit -m <message>

Advanced: git commit -m <title> -m <description>

Best Practices for Writing Commit Messages

1. Clarity: Avoid vague phrases like “Fixed stuff” or “Done” (Which I am guilty of) can go a long way. Be direct, eliminate filler words like “kind of”, “something like that”.

2. Brevity: As much as your commit message should be descriptive avoid over Information. It is advisable that your First Line (Title) should be less than 50 characters and the body be less than 72.

3. Modular: Focus on one change per commit and describe it accurately.

4. Capitalization: Capitalize the first letter of the header.

5. Consistency: Using one format all through for commenting in a project. it is advisable you use an imperative mood for the subject line Like (“Add support for dark mode”

Some Commit types:

feat — a new feature is introduced with the changes
fix — a bug fix has occurred
chore — changes that do not relate to a fix or feature and don’t modify src or test files (for example updating dependencies)
refactor — refactored code that neither fixes a bug nor adds a feature
docs — updates to documentation such as a the README or other markdown files
style — changes that do not affect the meaning of the code, likely related to code formatting such as white-space, missing semi-colons, and so on.
test — including new or correcting previous tests
perf — performance improvements
ci — continuous integration related
build — changes that affect the build system or external dependencies
revert — reverts a previous commit

Example:

Putting all this together, here are some examples.

feat: add user authentication module

- Implemented login and registration functionality
- Added JWT token generation and validation
- Updated user model to include password hashing

docs: update README with setup instructions

- Added detailed setup instructions for new developers
- Included steps for setting up the development environment
- Updated contact information for project maintainers

Challenge For You

Here is a challenge for you before every push, set aside at least 3 minutes to write a Good Commit message.

Connect with Me!

I’d love to hear your thoughts on writing effective commit messages! Whether you have additional tips, questions, or would like to discuss best practices in software development, feel free to reach out:

• LinkedIn: www.LinkedIn.com/in/favouridowu

• GitHub: www.github.com/Favouridowu02

• Twitter: www.twitter.com/favour_eng

• Email: favouridowu02@gmail.com