Why You Should Write Small Git Commits

Small commits that are easy to understand are the backbone of great software development

Photo by Vlad Tchompalov on Unsplash

Most people involved in software engineering and programming should be familiar with version control systems like Git.

Usually, you stage the changes you did, write a commit message, and push the changes to a repository. Here’s an example use:

git add .
git commit -m "[#2313213] Fix XSS vulnerability in tooltips"
git push
# pushed 2 changed files to the repository

However, you have probably seen commits that contain lots of changed files due to covering a variety of topics:

git commit -m "[issue-id] Fix XSS vulnerability in tooltips + Improve Accessibility in dropdowns + Add unit test for user-dropdown.component + Update dependencies"
# pushed 20 changed files to the repository

There are also commits where the commit message doesn’t tell you enough about what the intent of this commit is:

git commit -m "Did some changes"
# pushed 13 changed files to the repository

In agile environments using Scrum or other related agile methodologies, it is expected to deliver customer value fast and at regular intervals.

Influenced by a coworker, I tried to adopt his style of small commits and continuous improvement. As someone with interest in both business and the technology behind it, this approach resonates well with me.

Continuous Integration helps us to catch bugs and issues early

In this post, I want to briefly summarize why I like this approach. We’ll take a look at the advantages of small commits in software projects.

Advantages of Small Commits and Continuous Improvement

• Getting early feedback from both tools (e.g. unit tests on a CI server) and other people (developers, testers, product managers) which encourages the idea of continuous improvement and helps to avoid large changes in the future.
• Revert a commit with ease if something goes wrong. Big commits are harder to revert since you may not want to revert all of the changes but only a subset.
• Small commits are easier to understand when reviewing a pull request.
• Write better commit messages. Since small commits are usually more focused and less broad than big commits, it is often easier to state the purpose of a small commit.
• Improve your statistics (don’t take this too seriously).

Use the Right Tool for the Job

Sometimes, small commits are not possible or reasonable:

• Splitting code changes into too many small commits can actually make it harder to review. If you changed the name of a variable that is used in 12 files then you should not create 12 separate commits. Since these changes belong together, they should be committed together, not separately.
• If you do a lot of small commits then it is easy to end up with large pull requests which can be hard to review even though each commit for itself may be relatively easy to understand. Therefore, you should avoid long-running branches which goes against the idea of continuous improvement

Conclusion

Thanks for reading this short post about my thoughts about small commits in Git.

As you can see, there are lots of pro arguments for small commits in software projects. In my view, the most important aspect is getting feedback as early as possible. How do you approach this topic? Let me know in the comments.