Commit Frequency

How often should you commit?

I found this is a question that comes up a lot when talking about how to understand development.  It’s one of the base actions of software development, like clicking save on your Word doc, and, just like your Word doc, people have different behaviors around how often they save their work.

The general consensus is that you should check in early and often.  It’s with good reason too.  When you’re in a team of a dozen or more developers, it’s hard not to step on each other’s toes.  In fact, avoiding this conflict is one of the key benefits of a code repository according to the creator of git.  Increasing when and how often you commit helps share and communicate your code changes and updates in a structured and well-understood way.  You’re not left with huge reconciliation projects at the end of the feature development cycle.

This chart shows the commit frequency over time for the Allstacks team

Let’s take a look at what we can learn from this.  Like the Commit Volume chart, you can learn about how your developers are adhering to this core bit of wisdom.  [Nearly] All of our developers commit at least once per day, showing a value of >1 here.  This is good, and in general, a minimum for high functioning teams. In fact, one of our developers even peaked at almost 5/day.

There are varying suggestions on how often a developer should commit. Although opinions can range from every 15-30 minutes to only when you complete a feature or bug, a lot of this is team culture and style dependent.  For teams where most of the bugs are simply text or formatting changes, it’s possible that a team member can complete 10 in an hour, and make a commit each time.  However, for larger projects, like API changes or ORM changes, it’s possible that the code changes don’t reach stability for a few days.

Find the frequency that works best for your team, culture, project lifecycle, and technology.  From there, you can identify when you’re off track.

It’s important to understand what’s healthy for your team and track it.  While you may not know this offhand, it’s easy to look back at your key developers and understand what is effective.

Leave a Reply

Your email address will not be published.