In response to my recent claim that neither merge nor rebase is the best approach, subscriber Ben Hubbard wrote me the following question (shared with permission):

Alright – I see where you’re coming from with the ‘neither argument. What usually stops my team from merging quickly is required reviews before merge. I know you’ve mentioned in the past that code review should be a top priority; what if I’m on a team of two, and the other doesn’t share my working hours? Should we be merging freely into dev, and only reviewing on promotions to main?

Here’s my reply:

Hi Ben,

This is a common question. I’ve been in the situation many times in my career. So it definitely deserves attention.

I don’t think there’s a single magic bullet approach that will work, but I do think there are a number of techniques we can use to help solve this problem of async code reviews:

• Stacked diffs While I believe this should be a LAST RESORT approach, because it manages the problem, rather than eliminating it, I mention it first, because it’s often the most obvious approach for a person/team accustomed to large feature branches, and it probably requires the least workflow change. In short: Create your large feature branch locally, but when you create a PR, create a PR only of the first set of commits. Once that’s merged, rebase your local feature branch on main again, then create another PR from the next few commits. Rinse and repeat. There are tools (both third-party, and built into git) to streamline some of this. Maybe I can talk about more of this in a longer future post.

• Work on multiple things at once. Another LAST RESORT approach, but another common one. Once you’ve created a (small) PR for feature A, and are waiting for review, move on to feature B, and work on that until you have a small PR ready. If you have pending PRs for all relevant branches, create some small PRs for code tidyings or delinting, or other small technical debt stuff. This isn’t ideal, because it means context switching and, probably more important, by definition, it means you’re not working on the most important thing all the time.

• When possible, review code after merge. MOST code review isn’t about quality gating. Most often, code review is really about keeping the team in sync with your changes. Knowledge sharing. This can just as effectively happen after merge as before merge. So when possible, merge your code, then let your colleague review it after the fact. Except for critical code paths, or with code your colleague is more familiar with, this should usually be fine. Anything they want you to change can be changed after the fact and merged later anyway.

• Skip code review entirely, when it’s safe. Many changes don’t require code review at all. Fixing a typo in a comment? Reformatting some code? Making a trivial bug fix? Writing some new tests that don’t change functionality? Maybe even some feature changes in non-critical code… you decide for your context. But agree to not review such trivial things, and just merge them.

These last two approaches work best when there’s high trust on the team. With just two of you, hopefully that’s not a big ask. If you can trust each other to use good judgement to only merge without review those things which are appropriate, then you’re set to go. If you don’t have that trust, there are some tools to help with this. One I recall uses machine learning to try to determine whether a PR needs human review, or otherwise merges it automatically. I’m not a fan of using machine learning as a substitute for human trust, though. So use trust, if possible. The Ship/Show/Ask framework can be a good one for this.

I hope some of this helps!

Jonathan