Keep Your Commits Small

Every developer knows the good practice of performing small commits (at least every developer who has not spent the last few years within a cave). It considerably facilitates change tracking. Commit messages are more accurate and it is easier to learn the purpose of each revision. It is easier to revert problematic changes and use the bisect mechanism to find specific commits. And if you are pushing your changes as frequently as commit, you will not lose weeks of work by an accidentally entered command or disk crash.

However, the practice is not only about commits. The whole development process can greatly benefit from it. As a result, each small commit should go through it separately. It starts with a small local change commit and push. It is followed by a slight review, possibly by a pull request. Next there is a small integration to the main development branch (or feature branch) and Continuous Integration system execution, usually running all tests against the change. The process of course can slightly differ depending on a specific project and company.

Such an approach has many benefits. It solves a lot of problems encountered during large commits and their integration. Here are the most obvious and visible ones:

• reviewer can detect early whenever a developer is going in the wrong direction - there are no situations when a developer left alone for a week will implement a solution that is a dirty hack. It reduces wasted development time, and moreover, prevents situations when such implementations are accepted due to the time pressure,
• reviewer or specific project owner can maintain a clear picture what is under development - thanks to small reviews he is up to date with all current changes. It is easier to foresee potential problems within the project,
• small pull request/change is much easier to review - large changes are very troublesome to review and drains a significant amount of energy. Often they are not performed diligently and thoroughly enough. As a result, bugs may slip into the product,
• it is easier to measure the development progress - issue status is more visible in comparison to situation where developers are buried for a week within their tasks,
• it is easier to maintain good quality and proper code coverage - with small changes it is easier to incrementally improve it. There is no situation where some developer was coding for weeks and then needs to adjust his/her code to the quality rules and write tests (so much against TDD),
• CI integration is much easier -  small changes have lesser chances to break something and are easier to fix. There is also a lesser chance that such commit will conflict with other developer changes,
• there are no major conflicts between several developers changes - there will be no situation where three developers implementing three different features would solve the same problem in three different ways resulting in difficult conflict resolution and major refactoring of their features.

Which change is small and which is not? The size shouldn’t be judged on time spent by a developer on it. Most of us were in the situation when a week of effort resulted in 20 lines of code. Not very good but still a fair enough measurement is lines of code. Reviewing about 200 lines shouldn’t take more than an half an hour (of course, as always, this depends on the project and technology) and should not be a very troublesome job. Some developers prefer even smaller changes. The clue is that you should feel that the changes are small, light, and can be easily pushed through the whole development pipeline.

Depending on the project, there will be more or less different advantages from such an approach. However, no matter what project methodology you are using, additional effort would pay off for sure. It will not only facilitate the development process, but also keep your team moving smoothly and motivated.