How To Break A Big Pull Request Into Multiple Smaller PRs?

Have you ever got a chance to review a Pull Request that contains the change across 100 different files?

If you have not then you are in a wonderful place. But if you have… then this article is for you and your team.

Big PR takes a lot of time, concentration and focus to understand what all parts of the code have changed. This is such a turn-off for the reviewers that they might develop a grudge against you for the rest of your life (😂 I’m joking). No, I’m not joking. This is a serious issue.

Bigger the PR, the higher the risk.

You increase the size of the PR, you increase the risk.

Risk is directly proportional to the size of your PR.

The more un-related files you touch in the PR, the higher are the chances of you getting fired.

Are you getting my point? Or do you want me to repeat everything once again?

Just let me know in the comments below and I will repeat it for you.

So with that said… let’s get to the meaty part of breaking the bigger PR into 2 or multiple smaller PRs.

Do everything at once if you have to with lots of small commits…

Take this advice only if you are working in an environment where you end up working on a big feature and then later merge once everything is done. If you are already working with smaller features then finish that, raise a PR and start working on another feature.

Commit often.

Make this your habit. The sooner you adapt to this the better. The more frequently you commit, the more risk you avert. Don’t keep the code in your machine for long.No matter if you are working on your own project or working for some company. The longer you keep the code with you the more risk you gather. So, commit the code as frequently as you can.

I’m saying all this stuff because I truly care for you. I don’t want you to end up with me and throw jupiter size PRs all over the place. I will find you, and I will kill you.

Now the meaty part.

You have made small commits and finally finished the entire feature. Tested it and made sure everything is working fine.

The time has come to raise a PR.

Example Branches

• jupiter (branch that contains all the code)
• mercury (small PR 1)
• venus (small PR 2)

You end up with a big Jupiter branch after making all the changes.

Run the below command:

git diff jupiter master

It prints out the diff patch like this,

This diff patch is important. This is how git knows what is changed.

Now, save this patch to some file.

git diff jupiter master > /var/tmp/jupiter.patch

This will save the diff patch to a file called jupiter.patch

Now… checkout to the master branch.

git checkout master

Now… create a new branch mercury from the master,

git checkout -b mercury

Apply the patch file that you created before,

git apply /var/tmp/jupiter.patch

This will apply all the changes of Jupiter branch on top of master. But these will be uncommitted, untracked changes.

Now all you have to do is carefully select the code to commit. I’ve started using IntelliJ for selective commits because it provides an interactive UI where I can make the code changes if I need to. And it cleans up the code before merging as well. So that’s kind of added benefit.

But for the sake of this tutorial, I will keep to the terminal.

Great!!! so where was I.

Alright, we have applied the patch so far.

The next step is to selectively add the code that we want and reject the code that we don’t want. And the best command for that is –

git add -p

The small -p at the end will ask you before adding the snippet of the code. And you can decide whether you want to select it or reject it using y or n.

Good progress.

So, you just go through the entire code bit-by-bit and decide whether you want to add it or not. It is that simple.

And if you have created some new files in the process which were not there before then you will have to show the intent of adding them and not actually adding them. So, git offers –intent-to-add. This adds the file but not the content of the file.

git add <filename> --N 

Now, you will have to manually remove the content of the file that you don’t want to keep, this can be easily done with --patch AKA -p

git add -p

But this time instead of selecting y or n , you select e. With e it will open up the file in the vim editor, now make your edits there and write it.

:wq

This will only add the code to the changes that you just made. That’s why I switched to IntelliJ for these things. Editing is so much easier there.

Now commit and move on,

git commit "feel proud you did a good job"

Great!

Once you have added all the changes to your PR and made sure your code works. Spawn out another branch venus from the same branch.

git checkout -b venus

Now, all you need is to add the remaining changes to this branch.

git add -A

TaDa!!!

All the changes have been tracked now.

git commit "it's time to take a big break"

git push

Conclusion

Be responsible and make small PRs.

A good developer is someone who knows how to keep his peers happy by writing good code and making small PRs.

I think that was helpful.

I’m running out of ideas, please let me know if you want to know about something specifically.