A Practical Guide to Stacked PRs Created for When Reviews Fall Behind by a Week Due to Massive PRs
TuBrief 편집팀
2026년 8월 7일
0
Computing/Software원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
With the adoption of AI tools, the speed of code generation has become incredibly fast. However, review speeds cannot keep up. According to the 2024 DORA (DevOps Research and Assessment) report, teams with high AI adoption saw PR sizes increase by an average of 154% and review times increase by 91%. As a result, deployment cycles actually slowed down. Throwing over 1,000 lines of code at someone to review all at once strains anyone's eyes. To end this chaos, we need to transition to a Stacked PRs chain structure where code is stacked layer by layer.
Cutting up code blindly can cause compilation to break or dependencies to fracture. You need a solid criteria. Limit a single PR to 200 lines or less of changed code and fewer than 10 modified files so reviewers can finish in 15 minutes. Divide a giant feature into a chain of up to 3 child branches:
Strictly adhere to this order. Fix your branch naming convention to something like feature/<feature-name>/stack-<step>-<description>. The process of decomposing an already tangled 1,000-line branch (legacy-giant-branch) into a chain is simple.
First, update your main branch and back up the original.
`bash
git checkout main
git pull origin main
git checkout legacy-giant-branch
git branch backup/legacy-giant-branch
`
Next, create the Layer 1 branch from main and cherry-pick only the schema-related commits onto it.
`bash
git checkout -b feature/order-refactor/stack-1-schema main
git cherry-pick
git push origin feature/order-refactor/stack-1-schema
`
Now, taking Layer 1 as the parent, you can sequentially branch out Layer 2 and Layer 3.
`bash
git checkout -b feature/order-refactor/stack-2-service feature/order-refactor/stack-1-schema
git cherry-pick
git push origin feature/order-refactor/stack-2-service
git checkout -b feature/order-refactor/stack-3-controller feature/order-refactor/stack-2-service
git cherry-pick
git push origin feature/order-refactor/stack-3-controller
`
Choosing tools is also a consideration. A pure Git CLI costs nothing but takes more manual effort, while dedicated tools like Graphite are convenient but introduce costs and infrastructure dependencies.
| Evaluation Criteria | Pure Git CLI | GitHub CLI (gh stack) | Graphite / External Tools |
|---|---|---|---|
| Dependency Tracking | Manual branch Base setup | Local .git and GitHub metadata | Separate remote engine and Local DB |
| Rebase Automation | Manual work per branch | Run gh stack rebase command |
Automatically handle lower chains on commit changes |
| Learning Curve | High (Requires understanding Git principles) | Low (Install CLI extension) | Medium (Requires adapting to a separate dedicated UI) |
| Operational Stability | 100% standard Git compatible | Public preview state | Very high |
When using Stacked PRs, the most painful moment is when a request comes in to modify a parent PR. Because the commit hashes change, all the child branches attached below break. If you just run git rebase, commits will be duplicated. You must use the git rebase --onto syntax to specify the range to be sliced.
If Layer 1 has been modified, move to Layer 2 and reposition everything from the pre-modification Layer 1 commit point up to the current HEAD onto the new Layer 1 end point.
`bash
git checkout feature/order-refactor/stack-2-service
git rebase --onto feature/order-refactor/stack-1-schema feature/order-refactor/stack-2-service
git push --force-with-lease
`
Move Layer 3 onto the new Layer 2 in the same manner.
`bash
git checkout feature/order-refactor/stack-3-controller
git rebase --onto feature/order-refactor/stack-2-service feature/order-refactor/stack-3-controller
git push --force-with-lease
`
If you do this manually every time, humans will inevitably make mistakes. Create a shell script to automate sequential rebasing.
`bash
#!/usr/bin/env bash
set -e
STACK_BRANCHES=(
"feature/order-refactor/stack-1-schema"
"feature/order-refactor/stack-2-service"
"feature/order-refactor/stack-3-controller"
)
TARGET_BASE="main"
git fetch origin
CURRENT_PARENT="$TARGET_BASE"
for BRANCH in "BRANCH"
OLD_BASE=CURRENT_PARENT" "OLD_BASE" ]; then
git rebase --onto "OLD_BASE" "BRANCH"
CURRENT_PARENT="$BRANCH"
done
`
Don't forget to enable the conflict resolution history recording feature in your Git configuration. It will automatically handle recurring conflicts.
`bash
git config --global rerere.enabled true
git config --global rerere.autoupdate true
git config --global rebase.autoStash true
git config --global rebase.updateRefs true
`
Splitting a PR into 3 creates the issue of CI runners executing 3 times as much. You don't need to run heavy E2E tests on every single PR. Configure your GitHub Actions environment to run solid unit tests on lower layers and execute full integration verification only on the topmost PR.
Add stack position conditional statements to .github/workflows/ci.yml.
`yaml
name: Stack-Aware CI Pipeline
on:
pull_request:
branches: [ main ]
jobs:
fast-lint-and-unit-test:
name: Fast Validation (All Layers)
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Linter & Unit Tests
run: |
npm ci
npm run test:unit
heavy-integration-test:
name: Full E2E Test (Top Layer Only)
runs-on: ubuntu-latest
if: |
github.event.pull_request.stack == null ||
github.event.pull_request.stack.position == github.event.pull_request.stack.size
steps:
- uses: actions/checkout@v4
- name: Run Heavy Integration & E2E Tests
run: |
npm ci
npm run test:e2e
`
Setting up organization-level branch protection rules is also essential.
To properly run Stacked PRs, reviewers must be able to see the big picture. Specify the stack map in .github/PULL_REQUEST_TEMPLATE.md.
`markdown
Stack Overview
This PR is part of the Order Refactoring Stack chain.
Current Layer Scope
Dependency Status
`
Once the lower PR #101 is merged into main via Squash Merge, the GitHub UI Diff for the child PR #102 suddenly explodes. This is a phenomenon where even the code from the already merged #101 is captured as changes in the child PR. This happens because the SHA of the squash commit and the SHA of the parent commit differ on the Git Commit Graph. Don't panic; just elevate only the child branch commits onto main using the following sequence.
`bash
git log --graph --oneline
git checkout feature/order-refactor/stack-2-service
git fetch origin
git rebase --onto origin/main feature/order-refactor/stack-2-service
git push --force-with-lease origin feature/order-refactor/stack-2-service
`
Splitting a massive 1,000-line PR is not simply a matter of handling Git techniques. It is closer to an engineering task that neatly organizes the team's code review methods and overall deployment chain. When you encounter a messy legacy branch, create a backup first and try slicing it into 3-stage layers. Not only will the reviewer's fatigue decrease, but you will also gain much clearer control over your code.