Good Commit vs Bad Commit: The 5 Commandments of Git Bible

^{Originally published on Medium}

If you are accustomed to the world of software development, chances are you have heard of the term Git. Git is the de-facto version control system - a fancy term for a tool that helps you keep track of all the changes made to a project & enables multiple developers to collaborate on a single project.

Efficient use of Git is a necessity for anyone in the realm of tech!

What are commits?

One of the most commonly used features of Git is the commit feature, which creates & stores a snapshot of the project at a particular point in time, allowing users to revert back to that snapshot at any point in the future. Commits are usually accompanied by a message that describes the changes made in that commit.

In this article, we will go through the best practices of creating a commit, which will help you look like a pro to anyone checking out your projects

5 Commandments of Git Commits

Written down in the Holy Git Bible, these commandments are the key to creating good commits & maintaining a clean git history:

1. Thou shalt write clear, descriptive commit messages: Vague messages provide little context to the commit & end up making it difficult to keep track of the git history - they should be avoided like the plague. Always use clear & descriptive messages
   

    # Bad commit
    git commit -m "minor changes"
   
    # Good commit
    git commit -m "minor UI polishes to the auth flow"
   

2. Thou shalt avoid committing humongous changes: Stike a balance between the number of commits & the size of each commit. A commit should always be atomic & should NOT hold hundreds of files in most cases. Sometimes extremely rarely, would you encounter a situation where actually commit hundreds of files in a single commit is a good idea.

   One such example of an exception from my experience: one of my clients uses yarn cache to cache packages so that the CI/CD pipelines don't have to download the packages every time (thus preventing reliance on NPM & mitigating a point of failure for our pipelines). But when we install new packages, the changes often span across hundreds, if not thousands of files - here adding all the changes in a single commit makes sense due to the nature of the changes.

3. Thou shalt keep commits atomic: As mentioned above, changes should be atomic & multiple changes should NOT be bundled, even when it's small - this adds the ease of isolating bugs, reverting changes when needed & making the review process much simpler!
   

   # Bad commit
   git commit -m "fix sign out not redirecting to the home page, minor UI polishes to the auth flow, add test setup for the auth flow"
   
   # Good commits
   git commit -m "fix sign out not redirecting to the home page"
   git commit -m "minor UI polishes to the auth flow"
   git commit -m "add test setup for the auth flow"
   

4. Thou shalt follow a structured commit format: Following a pre-defined structure for commits can make the git history look consistent & easy to follow. Personally, I like to follow the Conventional Commits standard, which is widely used in the industry.
   

   # Bad commits
   git commit -m "update expo sdk"
   
   # Good commit
   git commit -m "chore(expo): update sdk to 52.0.37"
   

5. Thou shalt test before pushing changes: Always test your changes locally before pushing them to the main branch. This will prevent breaking the code & save you from the wrath of your team members!

Best practices

1. Use branches efficiently: Create separate new branches for each feature/bugfix. Raise PRs for reviews & merge it into the main branch after approval
2. Write clear & descriptive commit messages: Each commit in a PR should be self-explanatory on what was changed & build-up to the final feature/bugfix addressed in the PR
3. Strike a balance between the number of commits & the size of the commit: Each commit should make a meaningful contribution to the scope of the PR, but don't bundle all the changes in a single commit.
4. Squash commits before merging to the main branch: If you are a project owner, leader, admin, or someone reviewing the code, before merging a branch in the main one, consider squashing the commits from the PR during the merge. This practice keeps the commit history clean and easy to follow, especially when working on a real-world project with potentially thousands of PRs & millions of commits.
5. Use Git Hooks to automate the process: A brief overview of Git Hooks - Git can fire off custom scripts when certain actions occur, this can be used to automate the process of linting, formatting, testing, and even check whether the commit message follows a certain format. This will help you maintain the quality of the commits seamlessly without requiring manual intervention. You can check out one of my older articles on how to set up Git Hooks with Husky

Conclusion

Now you are well-versed with the commandments of the Holy Git Bible & would easily be able to sniff out bad commits from miles away!

NOTE: Git Bible is a fictional book - resemblance to any real book is purely coincidental & unintended

That's all folks! 🎉

Thanks for reading

Need a Top Rated Software Development Freelancer to chop away your development woes? Contact me on Upwork

Want to see what I am working on? Check out my Personal Website and GitHub

Want to connect? Reach out to me on LinkedIn

Follow my blogs for bi-weekly new Tidbits on Medium

FAQ

These are a few commonly asked questions I receive. So, I hope this FAQ section solves your issues.

1. I am a beginner, how should I learn Front-End Web Dev?
   Look into the following articles:

   1. Front End Buzz words
   2. Front End Development Roadmap
   3. Front End Project Ideas
   4. Transition from a Beginner to an Intermediate Frontend Developer

2. Would you mentor me?
   
   Sorry, I am already under a lot of workload and would not have the time to mentor anyone.

Comments

[Aditya Mathur]

I think that to be a good developer, one should master the use of git. One of the most important things when working in an environment with many developers.

[Tapajyoti Bose]

Agreed