If you aren’t a part of the development world you may find this post boring, confusing and not at all applicable. If you are a part of the dev world this post may appear monotonous, overplayed or unnecessary. Either way you should continue reading because you never know what kind of golden nuggets of knowledge you may find in a random blog post!
It’s not news that keeping pull requests small is best practice and fairly simple, and that using micro commits within those PRs is very useful. However, I’ve often found myself not practicing what I preach, and recently stepped outside myself to reestablish why it’s best to follow these practices. If you aren’t already, or you’ve found your PRs and commits becoming larger, I’d highly encourage you to get back to those basics.
Smaller PR benefits
- Quicker approval
- Easier to fix code when changes are requested
- Better feedback
- Easier to rewind code if needed with minimal loss
- More organized PRs with clearer commit messages
- Consistent code checkpoints/backups (remember to push your commits)
- Improved code review process
- Organization and clarity
- Easier to stay on task — breaks up a larger task into smaller, easier to complete tasks
- Increased project/feature scoping accuracy
- Easier collaboration
- Better representation of project progression
Along with these benefits come some challenges such as knowing the best way to dissect the project into small enough tasks that still efficiently log code iterations. Another challenge to avoid is the accidental creation of unused code. Sometimes I create repetitive code with the intention of refactoring and cleaning up after myself afterward, but the latter doesn’t always happen. Coming up with good strategies to minimize the challenges that come along with shrinking commits and PRs is very important. These resulting strategies shouldn’t be viewed as a workaround, but rather a new part of your coding game plan that should fall under the “best practices” umbrella.
Personally, I’ve found that the benefits of smaller commits and pull requests outweigh the cons — and their solutions — and it’s not even close. There are many other strategies in the development world that are considered best practice, but these two in particular have helped me grow and improve as a developer leaps and bounds further than what I was before using them. I’m sure those that aren’t already minimizing commits and PRs, who are willing to try it, will see similar perks.