LabHub

Blog

Modern Code Review and Merge Pipelines — PR, Merge Queue, Stacked PRs, Monorepo, AI Review, Trunk-Based, Husky, Semgrep Deep Dive (2025)

2026-04-15 · 12 min read · #code-review#pull-request#merge-queue#monorepo#stacked-prs#ai-code-review#trunk-based#git#semgrep#developer-experience

한국어English日本語

Code review is half the job — why do we barely talk about it?

Assume an engineer reviews 3–5 PRs per day. Five days a week, fifty weeks a year, and you are up to 1,000 PRs annually. Reading, judging, and suggesting on other people's code may exceed time spent writing new features. Yet we say remarkably little about it. "I balloon PRs because I dread reviews," "I sat unapproved for two weeks," "a reviewer missed the bug that caused the outage," "AI review is spam" — every day.

2025 is reshaping the landscape. Cursor, Copilot Review, CodeRabbit, and Greptile ushered in the "first-pass review is machine" era. Graphite, Sapling, and Jujutsu pushed Stacked PRs into mainstream workflow. Merge Queue became a GitHub native feature. Monorepo tools (Nx, Turborepo, Moon, Bazel, Buck2) had a generation change. Trunk-based Development moved from "ideal" to "default."

This post dissects 2025 code review and merge pipelines.

A continuation of the Platform Engineering and Observability posts. Platform is "self-service delivery"; code review is the "quality gate for code change."

Part 1. PR Sociology — How Not to Be a Blocker

1.1 Why reviews hurt

1.2 Four traits of a good PR

  1. Small — under 400 lines (research shows peak defect detection)
  2. Single concern — don't mix refactor with feature
  3. Context in the body — what, why, how tested
  4. Self-review first — author comments on their own diff first

1.3 Four reviewer principles (Google Code Review Guide)

1.4 Conventional Comments

Prefixes separate blocking intent from emotion.

praise: thorough test cases
nitpick: clearer name - userId -> userIdentifier
suggestion: extracting this into util would help reuse
issue: race condition here - TOCTOU
thought: A/B test needed later?
question: any reason retry count is 3?

Part 2. Code Owners and Reviewer Assignment

2.1 CODEOWNERS file

# /auth/** requires security team review
/auth/**                        @org/security
/packages/payments/**           @org/payments-team
/infrastructure/terraform/**    @org/platform
*.md                            @org/docs

2.2 Auto reviewer selection

2.3 Review load balancing

Part 3. Merge Queue — 2024–2025 Default

3.1 The problem

3.2 What Merge Queue does

  1. Queue the merge request
  2. At queue head, simulate build on "current main + this PR"
  3. On pass, perform the actual merge
  4. On fail, send back to author

Google and Facebook have run this internally for 10+ years. GitHub native since 2023, default-recommended in 2024.

3.3 Tools

3.4 Batched Merge

Large monorepos batch multiple PRs per merge. On failure, bisect to find the culprit PR. Needed only at Meta/Google scale.

Part 4. Stacked PRs — Splitting Big Changes

4.1 Problem

4.2 Solution

Stack changes into multiple PRs, each small. When the leading PR merges, the next auto-rebases onto main.

main <- PR1 (schema) <- PR2 (API) <- PR3 (UI)

Review each PR independently. Manual stack management becomes rebase hell.

4.3 Tools

4.4 Why Jujutsu matters

Part 5. Monorepo vs Polyrepo — 2025 Verdict

5.1 Monorepo wins when

5.2 Polyrepo wins when

5.3 Pragmatic consensus

Google/Meta run 100k-engineer monorepos. Startups often "start small -> merge into monorepo as they grow." 2024–2025 trend: "services in monorepo, OSS libraries in separate repos."

5.4 Monorepo essentials

  1. Fast build cache (Remote Cache)
  2. Affected Detection — only build/test changed projects
  3. Merge Queue — parallel merge of heavy PRs
  4. Auto Code Owner routing
  5. Scale-grade Git — partial clone, LFS, VFS

Part 6. Monorepo Build Tools — Nx, Turborepo, Moon, Bazel, Buck2, Pants, Lerna's End

6.1 JavaScript/TypeScript-centric

6.2 Language-neutral

6.3 Selection tree

6.4 Remote Cache

Common battleground. Turborepo/Nx via Vercel/Nx Cloud, Bazel via BuildBuddy/Remote Build Execution, Buck2 has its own protocol. Teams going from 5 min CI to 30 sec usually did it via Remote Cache.

Part 7. AI Code Review — 2024–2025 Explosion

7.1 What AI does well

7.2 What AI cannot do

7.3 Tools

7.4 AI review adoption tips

Part 8. Trunk-Based Development

8.1 Definition

8.2 Why it wins

8.3 Death of Git Flow

8.4 Feature flag development

Part 9. Git Techniques — Rebase, Squash, Linear History

9.1 Merge vs Rebase debate

9.2 Team policies

9.3 No force-push to shared branches

git rebase + git push --force on shared branches is disaster. Defend with --force-with-lease. GitHub now blocks force-push on protected branches by default.

9.4 Conventional Commits

feat(auth): add passkey support
fix(payments): handle stripe timeout
refactor(db): extract repository interface
chore: bump deps
docs: update README

Part 10. Pre-commit / Pre-push Hooks — Local CI Speed

10.1 Hook managers

10.2 Essential hook set

repos:
  - repo: local
    hooks:
      - id: lint
        name: eslint
        entry: pnpm lint --fix
        language: system
      - id: typecheck
        entry: pnpm typecheck
        language: system
      - id: test
        entry: pnpm test:affected
        language: system
      - id: secrets
        entry: gitleaks protect --staged
        language: system

10.3 Why hooks get hated

Part 11. Static Analysis — Semgrep, SonarQube, CodeQL, ESLint

11.1 Semgrep

11.2 SonarQube / SonarCloud

11.3 GitHub CodeQL

11.4 ESLint, Biome, Oxlint

11.5 Security-specialized

Part 12. CI Speed — Why PR Merge Must Be Under 10 Minutes

12.1 Compound effect

12.2 Strategies

12.3 Flaky tests

Part 13. Practice — Pipelines by Team Size

13.1 5-person team

13.2 50-person team

13.3 500+ engineers

Part 14. Checklist 12, Antipatterns 10

Checklist 12

  1. Average PR size under 400 lines?
  2. PR merge P50 under 24h?
  3. CODEOWNERS current and functional?
  4. Merge Queue blocking semantic conflicts?
  5. Stacked PRs a normal team workflow?
  6. Conventional Commits enforced?
  7. pre-commit/pre-push hooks fast (under 10s) and useful?
  8. Switched to fast linters like Biome/Oxlint?
  9. CI under 10 min average?
  10. Flaky-test detection/isolation system?
  11. AI reviewer spam rate under 5%?
  12. Trunk-based + Feature Flag standard?

Antipatterns 10

  1. Rubber-stamping a 1,000-line PR
  2. Empty PR title/body
  3. Long-lived feature branch over 1 month
  4. Habitual --no-verify
  5. Merging on AI approval alone
  6. Concurrent merges without Merge Queue -> silent conflict
  7. Papering over flaky tests with if (retryCount < 3)
  8. Unmaintained CODEOWNERS -> ghost accounts as reviewers
  9. Entire team's reviews funneling to one senior
  10. Rebase/Squash policy inconsistent -> history chaos

Next post — "The Engineering Blog Era: Technical Writing, RFC, ADR, Design Doc, Blog Operations, Communication"

If code review is one lever, technical writing is the next. RFC, ADR, Design Doc, internal wiki, external blog. Engineers who write well have 10x blast radius.

Code survives between people. The next post looks at that survival strategy.

Read the original: https://www.youngju.dev/blog/culture/2026-04-15-code-review-pr-merge-queue-monorepo-stacked-prs-ai-review-trunk-based-husky-semgrep-deep-dive-guide-2025.en

Comments

No comments yet.

Sign in to leave a comment