Do you commit frequently enough?

Daren Hayward
3 min readFeb 20, 2022

--

I used to think I committed fairly frequently, maybe 2–3 times a day. It seemed like a reasonable point where I’d developed something to a point where it was good enough for someone else to review or it was time for a break and a good point to stop and push upstream just in case the proverbial bus strikes.

Now I’m forming a new opinion.

Where did this come from?

Working my way through the iOS lead training program at Essential Developer I noticed that they commit often and it felt crazy, putting that into context during the time it took me to copy the code and fix my typos trying to keep up I committed an amazing 60 times in 3 hours, that’s 20-30 times the number of commits I previously performed in a day! Note the Essential Developer team are committing at a faster rate, due to rewatching parts of videos to deepen my understand and resolve issues.

Is this level of committing too much?

Asked before this course and I would have thought you were mad and just committing for the sake of committing to get to that number of commits, now it’s starting to feel just right.

Person holding cup with text “See the good” on the side
Photo by Nathan Dumlao on Unsplash

Seeing the light

Why does it feel just right? It’s more about being agile, which most companies have adopted or are adopting in droves, where one of the fundamentals is to fail fast. Failing fast gives us the ability to quickly assess through experimentation and then correct course should something be wrong, enabling fast and efficient development.

3 minute commits

I’m not advocating that as a target here, it’s just my current rate. But why commit that often? The answer lies again in being agile and using Test/Behaviour Driven Development, keeping the loop really tight.

  • What is the smallest incremental change I can make?
  • Write the test for it & watch it fail
  • Write the production code to make it pass & commit
  • Refactor code for reuse, factory methods, ensure it passes & commit again
  • Repeat

Realisation

The benefit is you’re never far from a working code base and it’s easy to roll back.

The smallest change is one where something functional has been added, it starts with something really small like an expected failure case and once this small change is implemented, another piece of expected functionality is added, i.e. a different failure type.

Before you know it there’s a lot of commits with a completely tested code base including tests to ensure the expectations of the interface are met.

--

--

Daren Hayward

A family man with three girls with a heavy interest in software development. From embedded software to mobile applications, waterfall to agile.