For any team or developer who wants to improve their velocity, I recommend committing often. Committing often means breaking down your work into smaller chunks or checkpoints that can be committed. This is especially helpful for trunk-based development. Continue reading to see the benefits of committing often.
Easier Integration
For teams utilizing trunk-based development in their Continuous Intetration and Continuous Delivery (CI/CD) process, committing often makes integration and merges easier. The likelihood of conflicting with another members changes is drastically reduced when everyone makes small commits.
Faster Development
Development is actually faster when you commit often. Why you might ask? Smaller changes are easier to review and have less risk. When I make a small change, it is much easier and faster for me to review opposed to reviewing and ensuring that I covered all my test cases for thousands of lines of code.
Better Quality
With smaller changes, there are less likely to be mistakes as I review my code. I am focused on making the small piece as good as it can be. Making updates are easy and trivial.
Refactoring is heavily complemented by small commits. A commit can be applied to each refactor. This ensures that you have working code as you make changes and makes it easy to undo changes that do not work. Alternatively, undoing lots of refactoring means lost work and additional rework.
Ability to Pivot
On any team unexpected things can happen (ex. a high priority bug can come in). If you don’t commit often, you may have a lot of local code that is not available in the repository. You have a tough decision of saving your changes locally as a patch or delaying to get your local changes working to commit. Committing often alleviates this problem.
Unexpected Leave
Committing often also mitigates issues when a developer takes unexpected leave. Let’s say that this developer was working on a feature for a full week locally and cannot return to work for a week or two. Committed changes allows the team to pick up the work from where it left off and continue on.
How to Apply This Concept
The easiest way to achieve small commits is to plan and break down your work into chunks of production-ready pieces.
For example, if I am adding a “user” to the system, I could break the work up into the following:
- Create database table
- Create user entity in code
- Add service logic
- Add controller logic
- Update front-end code to display users
After breaking down the work like this, it is very easy to focus on each task and achieve them one-by-one and committing them along the way.
How Small
How small you make your commits is a personal judgement. Development is an art as well as a science. My recommendataion follows Martin Fowlers’: Try to commit at least once a day. I often find myself making up to 10 commits in one day depending on my work.