• Skip to main content
  • Skip to primary sidebar
BMA

BeMyAficionado

Inspire Affection

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

September 4, 2021 by varunshrivastava Leave a Comment

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 is just a random example from my code that you can find in my repository CodeWithVarun -> github.com/vslala

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.

Related

Filed Under: Programming, Tutorials Tagged With: code-review, git, programming, pull-request

Primary Sidebar

Subscribe to Blog via Email

Do you enjoy the content? Feel free to leave your email with me to receive new content straight to your inbox. I'm an engineer, you can trust me :)

Join 184 other subscribers

Recent Posts

  • Top 5 Common Design Patterns
  • Design A Notification System
  • A Well Functioning Team – Feedback Culture
  • Replication – How Is It Done In Distributed Systems?
  • Freedom From Redundancy Is A Trade-off

Recent Comments

  • Varun Shrivastava on How To Mock SecurityContextHolder in Spring Security using Mockito?
  • Franco Vedia on How To Mock SecurityContextHolder in Spring Security using Mockito?
  • Varun Shrivastava on Create Page Layouts with React and Typescript
  • Damilola Bells on Create Page Layouts with React and Typescript
  • Varun Shrivastava on Create Page Layouts with React and Typescript

Categories

  • Blogging
  • Cooking
  • Fashion
  • Finance & Money
  • Programming
  • Reviews
  • Software Quality Assurance
  • Technology
  • Travelling
  • Tutorials
  • Web Hosting
  • Wordpress N SEO

Archives

  • August 2022
  • May 2022
  • April 2022
  • February 2022
  • January 2022
  • November 2021
  • September 2021
  • August 2021
  • June 2021
  • May 2021
  • April 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • February 2020
  • December 2019
  • November 2019
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • January 2019
  • November 2018
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016

Copyright © 2023 · Be My Aficionado · WordPress · Log in

Go to mobile version