How to avoid merge pull request limbo
Sometimes git merge pull requests can take time and become long-lived, a source of frustration for many developers. Long-lived pull requests are pull requests that are stuck in a backlog without being approved and are in a merge limbo.
Although pull requests can enter this limbo state for many reasons, I’ve focused on a few below and propose new solutions:
Code Dependencies
One of the easiest ways is code dependencies.
Imagine that you are in charge of a feature that touches a technical debt heavy part of your code base. Being a great developer as you are, you take it upon yourself to at least do a little cleanup only to find that that code region was already a focus of another pull request with a major refactoring. You now have hard merge conflicts to resolve.
The problem with major dependencies between pull requests is that it creates complexity on the order and possibility of merging them. So as a result, they stay un-merged in a limbo as less coupled and simpler pull requests get the green light.
Priority Change
Another way for pull requests to stay in this limbo is requirement or priority change. You’ve been asked to develop a major feature only to find after two weeks that the requirements or the business priority changed. Even if there were interesting improvements inside a pull request, they now stay frozen as there is no drive to pursue further development.
Excessive Code Review
Yet another way is excessive code review. Your pull request touches a critical part of the code which you have little ownership of, summoning everyone to comment and suggest to-do lists of corrections for your pull request over many iterations. The problem becomes the speed at which you then are able to deliver your original pull request.
Deployment Postponement
Finally, as the process of merging and putting in production is the reason for a lot of stress, many developers tend to postpone a deployment and aggregate many pull requests into one production release. When deployment is not continuous or frequent, development tends to output more pull requests than ops are able to put into production and hence features can wait in queue for weeks.
Here are a few tips that may help you drive your pull requests into production faster.
Understand it’s a people game
At the end of the day, developers that are about to click the merge button ask themselves:
- What is the risk profile of this pull request? (as in: am I comfortable vouching for this? What if it blows up and I’m also responsible because I approved it?)
- Is it well designed? (as in: when we get to touch this code again will it be easy to modify?)
With that in mind, the easiest way to get a merge should be to create as much trust about what you’re developing as possible.
I find that the best way to make decisions that involve consensus is to get to people early in the process. This not only gets you good feedback but also gets a continuity which will help get a +1 or an LGTM.
Now, I’m not describing pinging developers in 5-minute intervals. My point is that a 5 min conversation about a design decision early on is much more advantageous than a 2 day back and forth code review comment session.
Helping people approve your pull requests can go a long way.
Distributed ownership
Divide and conquer is a great strategy to get things done because it scales as you have more resources.
When you’re developing a product and the decisions of all parts of a platform need to pass by one person, as that product grows over time, that person will have a hard time keeping up with reviewing code and doing other meaningful tasks. While working at Codacy, I’ve seen CTOs and VPs spending more than 80% of their time reviewing code.
Distributing ownership of parts of your product helps produce quicker decisions and integrate accountability of results.
It’s much easier to talk to Susan because she hasn’t been reviewing pull requests of her module/component/part of the product (e.g. Database interaction) than to ask Anthony to review another pull request on top of the 30 he already has to review.
With the nature of software, it’s very easy for a product to quickly grow larger than the capacity of one brain.
Dividing ownership of your product for your team will make for faster and more accountable merging.
Small commits and pull requests
It is already a best practice to commit often and commit a reduced number of lines of code. This helps the next reviewer do a faster job.
Resist the urge to refactor and develop a feature at the same time. The ideal approach is to separate into two smaller pull requests and at least get one by the reviewing commitee faster. Management, Marketing or Sales tend to have a hard time understanding technical debt which has to be constantly observed.
Review smarter
When one is reviewing a pull request, one should aim to be as efficient as possible.
There are a number of tips to be a faster code reviewer:
- Checklists: use checklists of things you should be looking for every time.
- Mentioning: Ask the people that know the most or have the most ownership of that code to speak up. There’s a great plugin that can help you do this: mention bot.
- Standardize: Create rules for your pull requests and be diligent in enforcing them. There’s a cool tool that can help you do this: danger.
- Automation: automate as much as you can from this process. The goal is to only review what matters because typically you have 10 other pull requests that require your attention.
At Codacy we can help you do this by creating a tunnel vision for your focus.
Until next time.
Edit: We just published an ebook: “The Ultimate Guide to Code Review” based on a survey of 680+ developers. Enjoy!
About Codacy
Codacy is used by thousands of developers to analyze billions of lines of code every day!
Getting started is easy – and free! Just use your GitHub, Bitbucket or Google account to sign up.
