How often should you commit your codes?

How often can you commit and push codes on remote? Which one is better, Batch or Atomic?

How often should you commit your codes?

From my experience in software development, I've seen two types of code committing :

1) Commit in relatively small batch of related files or task

2) Commit one change or one file at a time, that can be referred as atomic committing

For me, committing and pushing on the remote branch is like saving in video games each time you complete a milestone. The more you go in the game without saving, the higher probability that you lose more stuff from which you can recover.

Both approaches, nevertheless, have benefits and drawbacks.

Batch Commit


You can focus solely on your work. Once done, in a single batch, commit your whole suite of changes. This can be more productive as you spend less time adding files and writing your commit files differently or in smaller groups of files or changes.


For me the biggest drawback is - let's assume you are working on a few related files as an experimentation or research and development. After completing it, you see the solution is not good enough. Yet there are a few changes you want to commit. You have to go through all the files, one by one to see which one you want to keep and the ones you want to discard. By contrast, each time you think you have a good solution, you can commit and push it to remote without having to check all the files again. The less I think, the more willpower I have to focus on the actual work.

Another disadvantage is you can lose your work in a bigger scope. Assume you are working on a set of files with several changes and suddenly - due to a power failure, your files are corrupted. You lose everything you've been working on. There is no remote backup. Even when your work is in progress, the more you go without committing and pushing on remote, the higher the risk of you losing your precious work.

Tip: Commit early. Commit often.

Atomic Commit


Atomic committing, that is committing each change or one file at a time, gives you a better sense of fulfillment. You feel better after committing and pushing a small change - and you will feel better more often instead of delaying gratification (for one final big commit and push). Now imagine waiting ages before pushing your work to remote.

You also have something to show meanwhile. Your colleagues such as your superiors, product owners or project leads can follow your work sooner than later.

With atomic committing, you can easily commit a small patch of code you think is useful and experiment on several variations without having to stuck on first solutions. Now if you are not satisfied, you can easily revert to your latest change and do that every time.


Committing your changes more often takes more of your time. It can also take more resources on the remote server if the programmers commit a lot and CI launches each time for quality tests.

In my opinion, however, the PROS outweigh the CONS.

Finally, another excellent reason of committing your codes early and often - particularly before going back home after a great day at work - is just imagine, on the next day, for whatever reason (windows update for instance), the disk drive on your computer crashes.

Imagine you did not commit and push your work on remote. You have to do everything again, unless you can retrieve the data. This is a loss of productivity and unnecessary stress that can be easily avoided - even though, this failure scenario might rarely if ever happen; better be safe than sorry.

As human beings we are usually more optimist than realist; we therefore tend to ignore real risks and setbacks that may happen to focus on the narrative of doing less and getting rewards nonetheless.