Skip to main content

How to Keep PRs Small When Features Depend on Each Other

· 3 min read
Darren Lin
Darren Lin
Blogger

We all know that huge Pull Requests are a pain. Most teams suggest keeping PRs between 25 and 200 lines because they are easier to review and less likely to introduce bugs. But what should you do when you are working on a new feature that depends on code you just wrote in another branch?

Instead of cramming everything into one giant 1,000 line PR, you can use Stacked PRs to keep your git workflow smooth and clean.

Scenario​

Imagine you are assigned a ticket that covers multiple functions. These functions are dependent on each other. If you wait until everything is finished to send a single PR, the diff will be massive. Your teammates will find it harder for them to spot logic errors.

In a real world workflow, you can't wait for the first PR to be merged before starting the next part of the task. That would be a huge bottleneck for your productivity

Solution: Stacked Branches​

To keep things moving, you can break your task into smaller pieces: Feature A, Feature B, and Feature C. These are dependent and can be completed in order.

Here is how you handle it:

  1. Start Feature A: finish the core logic and make sure it matches the product or technical spec. Push your code and open the first PR.
  2. Start Feature B from A: instead of switching back to main, create your next branch directly from your current one: git checkout -b feature/B. Now you can keep coding without being blocked.
  3. Updating Feature A: reviewers will have feedback. When you need to make changes to Feature A, go back to that branch and fix it. To keep Feature B updated, switch back to the B branch and run git rebase feature/A. This keeps your work in sync.

Stacked Branches

Merging to Main​

Once Feature A is approved and merged into the main branch, you just need to point Feature B to the main branch to keep the history clean.

  1. Update your local main: git checkout main and git pull origin main.
  2. Rebase Feature B: switch to your B branch and run git rebase main.
  3. Handle any conflicts: if you modified the same files in both branches, Git will ask you to resolve the conflicts. Just keep your latest updates and continue.

By following this process, your PR for Feature B will only show the code that is specific to that feature. It stays focused, atomic, and easy to read. Your teammates can provide better feedback, and you can keep shipping code without waiting for a merge.