How to merge code faster
Practical strategies for creating pull requests that get reviewed and merged quickly while respecting your team's time and improving SDLC metrics.
Intro
Preparing a pull request for success is not something you often hear people discuss. However, it is something that definitely sets you apart, improves you as an engineer, and helps your team stay on track with delivery.
This is not a definitive guide, but rather my favourite highlights of what I learned on a journey from freelance work to startups and small to medium-sized enterprises.
Why bother?
Apart from many other things, an atomic, monopurpose Pull Request is a crucial "must-have" for medium- to large-sized codebases. But why?
Imagine a Pull Request with 100+ files and 150+ commits. And it's your job to review it. Tediously, file-by-file, with attention to details and understanding the context.
Most likely, you will find a thing or two (or dozen) that doesn't match the repo's standards, and you leave comments, suggestions and questions. Days go by, and you receive a re-review request. Now it's even harder…
Apart from the old code, there's now more new code and commits, and the history of your discussion does not make it simple either… How about 5 PRs like this? There's just no time left to do your job.
I'm dramatizing, but honestly, you can cut these numbers in half, and it still would be as painful.
So why bother? Good PRs are easier and faster to review. Good PRs do not necessarily mean perfect code, so the ripple of infected changes is easier to revert. Good PR will improve your relationship with the team. You respect their time, they will respect yours, and that's worth a lot.
Bad practices
Before diving into good practices, let's take a look at pitfalls to avoid.
Including not related changes
Not only does it make it harder to review, as the context is no longer as sharp, but it also increases the cost of mistakes. With atomic PR, there's no harm in reverting, fixing, and pushing again. Yet, when PR has many unrelated things, reverting feels like an uncontrollable helicopter crash.
Assigning too many people
In my world, it's more than two. On the one hand, it's wasting too many resources (engineering hours); on the other, it's like asking for help from a crowd. When too many people are responsible, then nobody is.
Ignoring template
Generally bad practice. If you don't feel like the current template makes sense, raise it with your team, but don't ignore it. Most of the time, the admin puts it there for a reason.
Messing up with branch history
You may say it's a controversial one, but having a messy commit history means that your reviewers have one tool less in their arsenal to speed up the process. A clear, encapsulated, and structured commit history makes it 10 times faster to review.
Mixing business logic changes with prettifying
Makes it harder to read the file when it's not clear which changes are meaningful and which are just code formatting. Yet another bump on the way to approval.
Good practices
Why not the best? Well, it's up to a team to decide their best practices, but there are a handful of good-enough tips and tricks that increase the chance of a fast review.
Atomic PRs
Small, hyper-focused Pull Requests that solve one problem at a time. Apart from having a bigger margin for error, it's easier to find time to review 5–10 files than 20–50, just work-hours-math here.
Make a PR train (Stacking)
Sometimes, it's just a big chunk of work you need to do and merge. But slicing it into step-by-step pull requests makes it easier to digest. Just don't forget to base your current Part on the previous one, so that there are fewer changes to review.
Provide all the details
The problem you are solving, how you are solving it and what to pay attention to. The more context the reviewer has, the simpler it is to understand the change.
Record a demo
Or at least add a screenshot. It's better to see it one time than… well, you know it.
Test your changes thoroughly
You might be in a rush, or the change is really small, and it definitely works. At least it looks like it. Testing your changes will save time for all, you and your teammates. Try hard not to skip this check.
Make sense of your commit history
Squash related commits together, use meaningful names, and reorder commits if that will simplify commit-by-commit review.
Move lint/prettify/formatting/chores in a separate commit
I'm intentionally repeating myself, as I can't stress enough how much mental effort it takes to make sense of a whirlpool of functional and formatting changes.
Reverse review your code
That's my personal favourite, despite how many rules you broke, having a good old explanation on the spot will make reading it times easier. So, go file-by-file and leave comments for any ambiguities (should this comment be in the code?) (should you refactor if it that ambiguous?).
Assign an AI tool to review your PR
That's right, it's 2025, give humans a break. Tools like Copilot can somewhat reduce review time, so why not give it a try? Caveat: you might need to review Copilot's review, but that's the world we live in.
Check yourself for YAGNI, KISS, DRY
And other fancy abbreviations. It's challenging to review the smelly code, and it's even more difficult to block it, as it means the reviewer has committed to sticking with the PR until it's resolved.
Ensure business logic is covered by unit tests
As with previous practice, it's more closely related to the development itself. But having a good set of unit tests makes it less stressful to hit that approve button.
Recipes
There are weeks to follow rules and there are days to break them. Sort of.
Refactoring
Sometimes, you will inevitably need to change a large number of files. Refactoring and upgrading with breaking changes are the most common ones.
Avoid at all costs. But you did it. Still bad, but in this case, changes per file should be very similar, so it's relatively easy to check.
A good strategy would be to discuss your intentions with your team in advance (that's always a right step, tbh) and book a review session so you can walk them through your changes and answer any questions on the spot.
Feature
When working on a brand new feature or a proof of concept, it's easy to go wild and introduce too many changes. But you need them to make a point, to know that it works. That justifies your crazy git status, however, it's a good idea to simplify things for your teammates.
Again, slicing the changes into multiple PRs can not only simplify things for your peers but also speed up the review itself, as you can assign different people to your sub-PRs. Parallelism at its best!
By the way, IDE AIs like Cursor and Copilot do quite a good job in organizing those.
Enforcement
- Create a Pull Request description template that will cover all the necessary details
- Use a linter for common pitfalls and custom team rules
- Add pre-push hooks to ensure that the pushed code has no silly hiccups
- Use Code Owners and SMEs to increase the chance that the most relevant people are assigned
- Add copilot-instructions.md to (try to) reduce AI hallucinations
What's now?
There's no such thing as a perfect recipe for PR Success that applies to every team. Yet, as long as you communicate with your team and are respectful to your peers' time, the best approach will naturally emerge over time. Just make sure to document and focus on the good parts, and find ways to prevent things that slow the team down.