Dev.to

Stacked PRs for new devs

Stacked PRs: What They Are and Why You Should Care As a developer early in your career, you've probably gotten comfortable with the basic Git workflow: create a branch, make changes, and open a pull request (PR). But what happens when you're working on a large feature that requires multiple changes? Enter stacked PRs – a powerful technique that can make your development process more efficient and your code reviews more effective. What Are Stacked PRs? Stacked PRs (also called stacked branches or stacked diffs) are a series of dependent pull requests that build on top of each other. Instead of putting all your changes in one massive PR, you break them down into smaller, logical chunks that are reviewed separately but merge in a specific order. Think of it like building a house: First PR: Pour the foundation Second PR: Build the walls (depends on the foundation) Third PR: Add the roof (depends on the walls) Each PR represents a complete, reviewable unit of work, but they're designed to be merged in sequence. The Problem with Big Pull Requests Pull request review time is not linear with the size of the change. A pull request that’s twice as large takes more than two times as long to review — or, at least to review thoroughly. This usually means big PRs either tend to languish and grow stale or simply get rubber-stamped. Picture this: You start fixing what seems like a simple bug. Ten minutes in, you realize this "simple" fix requires: Updating a core utility function Modifying three different components Adding a new API endpoint Changing the database schema Suddenly, your "quick fix" has turned into a 500-line monster PR. Your reviewers open it, see the size, and either: Put off reviewing it (who has time to review 500 lines?) Skim it quickly (missing potential issues) Get lost trying to understand how all the pieces fit together This is where stacked PRs come in. Stacked PRs: Breaking Down Your Story Think of stacked PRs like writing a book. Instead of dumping the entire manuscript on your editor at once, you send: Chapter 1: Foundation and setup Chapter 2: Main character development Chapter 3: Plot resolution Each chapter builds on the previous one, but can be reviewed and understood independently. A Real-World Example Let's say you're adding a "Like" button to your website. Here's how you might break it down: Main Branch └── PR #1: Add database schema for likes └── PR #2: Create REST API for likes └── PR #3: Add frontend like button Each PR tells one part of the story: PR #1 sets up the foundation (how we'll store likes) PR #2 builds the bridge (how we'll communicate likes) PR #3 delivers the user experience (how users will interact with likes) Why This Approach Works Better 1. Clearer Context Each PR has a single, focused purpose. Reviewers can understand: What this specific change does Why it's needed How it fits into the bigger picture 2. Faster Feedback Instead of waiting for someone to review your massive PR, you can: Get early feedback on your database schema Start working on the API while waiting Adapt to feedback without massive rewrites 3. Parallel Development You don't have to wait for everything to be perfect before moving forward: Work on the frontend while the backend is being reviewed Address feedback on each layer independently Keep momentum going Example: Title: Add REST API endpoints for post likes This PR is #2 in the Like Button feature stack: 1. ✅ Database schema (#123) 2.

Feb 16, 2025 - 06:02
 0
Stacked PRs for new devs

Stacked PRs: What They Are and Why You Should Care

As a developer early in your career, you've probably gotten comfortable with the basic Git workflow: create a branch, make changes, and open a pull request (PR).

But what happens when you're working on a large feature that requires multiple changes?

Enter stacked PRs – a powerful technique that can make your development process more efficient and your code reviews more effective.

What Are Stacked PRs?

Stacked PRs (also called stacked branches or stacked diffs) are a series of dependent pull requests that build on top of each other.

Instead of putting all your changes in one massive PR, you break them down into smaller, logical chunks that are reviewed separately but merge in a specific order.
Think of it like building a house:

  • First PR: Pour the foundation
  • Second PR: Build the walls (depends on the foundation)
  • Third PR: Add the roof (depends on the walls)

Each PR represents a complete, reviewable unit of work, but they're designed to be merged in sequence.

The Problem with Big Pull Requests

Pull request review time is not linear with the size of the change. A pull request that’s twice as large takes more than two times as long to review — or, at least to review thoroughly.

This usually means big PRs either tend to languish and grow stale or simply get rubber-stamped.

Picture this: You start fixing what seems like a simple bug. Ten minutes in, you realize this "simple" fix requires:

  1. Updating a core utility function
  2. Modifying three different components
  3. Adding a new API endpoint
  4. Changing the database schema

Suddenly, your "quick fix" has turned into a 500-line monster PR. Your reviewers open it, see the size, and either:

  • Put off reviewing it (who has time to review 500 lines?)
  • Skim it quickly (missing potential issues)
  • Get lost trying to understand how all the pieces fit together

This is where stacked PRs come in.

Stacked PRs: Breaking Down Your Story

Think of stacked PRs like writing a book. Instead of dumping the entire manuscript on your editor at once, you send:

Chapter 1: Foundation and setup
Chapter 2: Main character development
Chapter 3: Plot resolution

Each chapter builds on the previous one, but can be reviewed and understood independently.

A Real-World Example

Let's say you're adding a "Like" button to your website. Here's how you might break it down:

Main Branch
└── PR #1: Add database schema for likes
└── PR #2: Create REST API for likes
└── PR #3: Add frontend like button

Each PR tells one part of the story:

  • PR #1 sets up the foundation (how we'll store likes)
  • PR #2 builds the bridge (how we'll communicate likes)
  • PR #3 delivers the user experience (how users will interact with likes)

Why This Approach Works Better

1. Clearer Context
Each PR has a single, focused purpose. Reviewers can understand:

  • What this specific change does
  • Why it's needed
  • How it fits into the bigger picture

2. Faster Feedback
Instead of waiting for someone to review your massive PR, you can:

  • Get early feedback on your database schema
  • Start working on the API while waiting
  • Adapt to feedback without massive rewrites

3. Parallel Development
You don't have to wait for everything to be perfect before moving forward:

  • Work on the frontend while the backend is being reviewed
  • Address feedback on each layer independently
  • Keep momentum going

Example:

Title: Add REST API endpoints for post likes
This PR is #2 in the Like Button feature stack:
1. ✅ Database schema (#123)
2.

Read More

Tags:

Previous Article

Optimizing Video Delivery with CDN and FFmpeg: Best Practices

Next Article

Weekly Challenge: Counting the XOR

Related Posts

Amazon Bedrock on EC2 Visual Studio LLM Project

Amazon Bedrock on EC2 Visual Studio LLM Project

Mar 3, 2025  0

Bridging the Gap: How Project Management Can Solve Developers’ Biggest Challenges

Bridging the Gap: How Project Management Can Solve Deve...

Mar 3, 2025  0

Dependency Inversion Principle (DIP) with Spring Framework

Dependency Inversion Principle (DIP) with Spring Framework

Feb 27, 2025  0