Have you ever submitted a pull request(PR) but it got rejected straight away because it’s too big? Well I did and you’ve got to give it to the reviewers, huge PRs are a pain in the ass to review. There are various reasons why PRs should be short and concise but I will not cover that in this blog. Instead I will share with you how I managed to split a big PR (it was some 2500+ new lines of code) into smaller ones (I ended up with some 7 PRs).

Let’s say that the project we’re working on has it’s main branch master, and a new feature branch was created based on that and we’re going to name it feature/cool_new_feature_branch. We then created a new PR, called it some_huge_pr, submitted it and it is now pending and active since you’re told that you need to break it down.

In my particular scenario I was working on an new web service and it also depended on other web services, where I also created some endpoints or done some changes, and therefore for me it was easy to break it down by feature (or web services in my case). Find a sensible way how to break down your work and plan ahead how you are going to split your big PR. Find common grounds and create small groups of code implementations.

Step 1

First thing we want to do is compare the differences between master and feature/cool_new_feature_branch. In your Git terminal type this command.

This command compares all the changes between master and feature/cool_new_feature_branch and creates a new file called huge_pr_patch_file in the root directory of your current Git connection. If you had to actually open this file you’ll find the code you wrote, in my case C#, with added Git syntax.

Step 2

Let’s switch back to master branch and create a new branch that will have just a portion of the new code. This will eventually be the new PR so we need to start thinking per feature here.

Step 3

Whilst checked in on the new branch run the following Git command to apply all the code changes from feature/cool_new_feature_branch to our new branch feature/first_small_feature_branch.

You should now be able to see a lot of changes in your new branch. From here stage any files you want, commit and push them. For this particular step I like to use Visual Studio’s Team Explorer tools. It displays all the files in a tree structure, and you can use Visual Studio’s file comparison feature. Then again, this is just my personal preference.

Step 4

After committing the staged files, we can stash all the remaining changes (that we will not commit in this branch) including any untracked files. From here proceed to open a new pull request as you normally would.

Step 5

Repeat steps 3 and 4 until all the code is committed and submitted into new smaller PRs. When splitting PRs be sure to include any code dependency and/or references so that the code compiles. If, when splitting, you notice that some of your code relies on code that is in another branch then create the new branch from that one. If not create the new branch from master.

In conclusion, I’m not going to lie, I’ve only used this approach once (just last week) and I’m no Git expert. Is it possible that there are more efficient methods or even tools that do the job? Yes, I wouldn’t be surprised but this method worked for me and next time I’ll face the same issue I will try to use this method again.

I hope it’s useful for you too and if you run into any issues feel free to drop me a message to fix this post. The one thing worse than not finding a solution online, is finding a solution that doesn’t work!

Until next one,
Bjorn