.png)
Commit frequency is an often-overlooked factor in maintaining code. Commits are like a "save" point in your project. If you've ever played an intense video game, you know that it's a good idea to save before every major fight or decision in the game, just in case you die to the boss or make an irreversible choice.
While vetting development firms for our network, we found that some firms didn't require their developers to commit code very often, and we saw commits as far as 2 weeks apart.
If you have two developers working on a project, a lot gets done (we hope) in 2 weeks. The code can be in a completely different state at the end. If a bug was introduced during the course of the 2 weeks, we'd have no way to know who or what caused the bug. Precious development time would be wasted trying to diagnose and then fix the issue, causing delays in our timeline.
On the other extreme, we wouldn't recommend asking your developers to commit every hour. Development can sometimes be a momentum-driven task and although committing only takes a few seconds, it can be enough to disrupt a developer's flow. Find a good commit frequency in between the two extremes and discuss it with your development team to see if they have any feedback.
At Aloa, we recommend committing twice a day, and once a day at the bare minimum (for each developer). We find the frequency of twice a day to be a good middle ground between committing too often and not often enough. A developer can commit their code before their lunch break and again before they leave the office for they day without disrupting their flow.
Thanks to our policy, if you discover a critical bug on Thursday, your developers can review the code one commit at a time to pinpoint the exact cause of the bug. They say "knowing is half the battle," and if you can immediately find the source of the bug, it significantly cuts down on the time spent trying to resolve the issue so your team can work on other features.
Running a business is hard,
Software development shouldn't be ✌️
