Along with Commit Frequency and Commit Volume, Commit Size is the final basic metric around the number of lines of code a developer creates. The size of individual commits is one of the biggest contributors to risky code. Even with a formal code review and unit testing policy, the larger a change, the easier it is to miss something. The general advice for commit size is just like Einstein said, it should be made as small as possible, but no smaller. Easy, simple to understand changes are more likely to both show errors and lead to developers inadvertently fixing errors that arise from complexity before they even commit.
The Allstacks team’s data shows a nice trend. While our most prolific developer has a higher average per commit, the range is still very small. There are no commits over 100 lines, and this is holding true even across our front-end/back-end boundary.
Each commit should be able to fit in the working memory of a developer
It’s difficult to place an ideal number on how large a commit should be, but each commit should be able to fit in the working memory of a developer. Otherwise, you run the risk of bugs or issues being missed in code review, or worse, production. This is also another metric that depends on your technology stack and your team. A great assembly team may turn out ten times the size features of an Alexa Skill team, but it’s important to identify your nexus of size vs. risk, where your value is maximized, and stay there.
This is also a good metric to show developer growth and team development. Many development teams strive to improve by making smaller, less risky commits, and it is actually a challenge for more junior developers. Helping to instill good coding practices by measuring what people are doing is one of the best ways to take your team out of the dog-house and to rockstar status within your organization.