min read ·
March 8, 2021

How to commit code more efficiently

Frequent code commits can be tedious but essential. Hence, it is vital to communicate the intent of changes effectively, so that team members looking at your code review understand the implications of those changes and review them adequately. These practices ultimately save time and improve communication in teams.

Photo by Yancy Min on Unsplash

Here are some of the design principles and guidelines that I have used to improve my workflow. I use them as a guiding light to ensure that any change to the existing commit workflow is effective and efficient. I am using Git as the version control system. However, these principles can be applied to any other version control tool.

Design Principles

It is essential to follow some design principles so that you can decide when a change introduced is reasonable as compared to over-engineering or under-engineering. It enables you to check the return on investment of the change. 

  • I want to use the same git workflow as much as possible, on different projects
  • My pull requests should be easy to review and debug
  • Have an easy way to set up my workflow and configure
  • Ensure linting and security of the code change
  • The commit message should communicate the intent of the change and not what the code does.


  1. Use git diff --check, which identifies any possible whitespace errors and lists them for you. You can add it as a git hook.
  2. Commit messages should be around 50 to 60 characters long, at max, similar to how one limits 120 characters per line when writing code.
  3. Make separate commits for logically separate changes.
  4. Use imperative tone for your commit messages. Example: Make IndexController check for token over Made changes to ensure IndexController checks for the token. It is more concise, and the intent of the change is understood right away.
  5. Use the .gitconfig file to set up the required info. It will make the commit more readable and secure. This depends on the use case, here are some examples that would live in the .gitconfig: 
       – GPG signature, 
       – Author info.
  6. Check if any sensitive info is part of the commit. An automated way should exist for checking this type of change. It minimises the security exposure when automated, and the cost of setup is minimal going forward. It's scalable when working in a team and more straightforward to enforce rules. Some tools to implement the checks mentioned above:
  7. Automate the git workflow as much as possible. Ensure the onboarding of this workflow is simple. You can make incremental changes over time.

Sources I have used for reference:


Need help with improving your development practices?

We would love to hear about your experience with version and deployment practices.

Tick (success) icon
Thanks for your message,
we will be in touch soon!
Oops! Something went wrong. Please try again later.