An OP asked the following question.

One of the redditor suggested something, I think, not especially wise, so I decided to correct him.

Redditor suggestion#

Why did you create separate branches for all of your small subtasks? That seems rather unusual. A more typical approach is to create a branch at the task or story level and use that as the unit for review and integration. Maybe, in some cases, you might discover that some work could be split off and integrated earlier, but that is more of an exception to make something specific more widely available.

Of course, there’s a big movement toward trunk-based development, but some prerequisites for that to be effective may not be in place yet if there’s a history of feature branching.

My answer#

Don’t do that. It’s basically the github flow. The real answer is to do continuous integration, for example trunk-based development.

For example, today I created 7 branches that merged into the master. I didn’t have to wait for reviewers because I was pair programming with my team mate. In one case, we held a team meeting because we were doing something unusual and wanted to get more opinions.

Basically the answer is:

  • Don’t do asynchronous code reviews
  • Review ideas before writing code
  • Use pair/mob programming, or call your colleagues before the code is finished to get feedback
  • Use TDD, and then you can merge you code to the master after each red-green-refactor cycle.

Why? Because if you review the code after it’s written, all the comments will cause some parts to be rewritten. That’s a waste. It’s better to shorten the feedback cycle and not waste time rewriting.

Another redditor suggestion#

Other person proposed something similar.

Did you make 7 branches and then submit 7 PRs all at once, or did you submit each PR as each branch was completed, and are still waiting on the first ones? If the former, you probably shouldn’t have done it that way; if the latter, seems like PRs are the bottle neck and you need to discuss with the team on how to speed them up so future branches can be based on previous changes. Perhaps you could reduce the number of branches by having each one contain more changes.

I also decided to correct that#

We can look at the problem from a Lean perspective. 7 PRs to merge is a muda (inventory). In my opinion, OP should not increase the batch size, but rather manage the queue and improve the flow of work by optimising processes.