"Could you make this PR (MR) smaller?", that’s either me leaving the comment (again) or just thinking it silently because I’m too drained to say it for the hundredth time!
Sometimes I have to keep repeating this same feedback like a broken record. Not because I love being that person (trust me, I don’t!) but because everybody knows those large pull/merge requests are a real pain in the ass. They’re more likely to break things, hard to review, and they’re just not fun to deal with.
The truth is, just telling people "keep it small" is not working. I mean, what’s “small” anyway? 🤔
Along this process I realized:
- What’s small for a docs update might be huge for an auth system change
- It can vary per person, what I think is a medium PR might be a small one for someone else
- Different codebases need different size definitions
- Without actual and automated agreements, we’re just throwing words around
- Nobody wants to be the "size police"
Why Does Size Matter Though?
Because big PRs create problems. They slow teams down, make bugs harder to find, and increase risk.
Think about reviewing code like proofreading a document. Would you rather:
- Review 10 pages, one chapter at a time
- Or get handed a 100-page document with "just a few changes"?
Yeah, I thought so.
When PRs are smaller:
- Your teammates actually review them (and faster too!) instead of rubber-stamping approvals
- The feedback is way better because reviewers aren’t exhausted
- It’s easier to spot potential issues
- If something goes wrong, it’s quicker to fix
So I Built Something to Help 🛠️
After dealing with this over and over, I decided to build a tool to help teams actually define and measure what "too big" means for their pull/merge requests.
I built pr-sizewise, a CLI tool that measures and reports pull request sizes for GitHub and GitLab, helping teams maintain manageable code changes. I know there are a few existing tools for this already, but this one has its own uniqueness. (And it was an interesting idea to keep yourself busy on a rainy weekend! ⛈️)
With SizeWise:
-
You define what "big" means, by setting your own limits for:
- Number of lines changed
- Number of files modified
- Directories affected
Supports both GitHub and GitLab
Smooth setup and configuration
To get the full value out of it, not just installing it as an automation tool that gets forgotten in a few months, I recommend these steps:
- Get your team together and define thresholds that feels right
- Start with bigger limits (you can always tighten them later)
- Share some wins when people make nice, small PRs
- Figure out what to do when someone really needs to make a big change (it happens!)
Sometimes you need bigger PRs, like when you're updating all your dependencies or doing a major refactor. That’s okay! Just give your team a heads-up, break it down into reviewable chunks if you can, and add extra context to help reviewers. It's way safer to ship a large PR like this.
Give SizeWise a Try
I’d love to hear how this works for your team:
- What size limits make sense for you?
- How do you handle different types of changes?
- What would make this even more useful?
And if you see it as a useful tool, a quick star on GitHub would mean a lot!
⭐️ https://github.com/behnamazimi/pr-sizewise
Remember, it’s not about being strict. It’s about making life easier for everyone.
Because at the end of the day, we all just want to ship good code without the drama. 🚀
🚀 Great insights, Behnam!