"매 PR — small, single-purpose, reviewable diff". 매 GitHub flow 의 unit of change. 2026 modern: AI-assisted review (Copilot, CodeRabbit, Claude) 가 매 first-pass triage, 매 human reviewer 의 architecture / intent 에 집중.
매 핵심
매 Why small PRs
매 review latency: 200 LOC PR 의 review time ≈ linear, >400 LOC 의 superlinear (review fatigue).
매 bug detection: small PR 의 defect rate 의 lower (Microsoft 2013 study, 2024 GitHub data confirm).
매 revert cost: small PR 의 cleanly revertable.
매 mental model: reviewer 의 hold entire diff in head.
## Why
<problem this solves; link to issue>
## What changed
- bullet 1
- bullet 2
## Test plan
- [ ] unit tests pass (`pnpm test`)
- [ ] manual: login → logout flow
- [ ] verified on Safari + Firefox
## Screenshots
| Before | After |
|---|---|
| ... | ... |
Stacked PRs (Graphite / spr workflow)
# 매 large feature 을 매 dependent small PRs 로 split
gt create -m "feat: add User model"# PR #1 base=main
gt create -m "feat: add User API"# PR #2 base=PR#1
gt create -m "feat: add User UI"# PR #3 base=PR#2
gt submit --stack
# 매 nit (preference, non-blocking)
nit: prefer `const` over `let` here
# 매 question (clarification)
q: why bypass the cache here?
# 매 blocker (must fix before merge)
blocker: this regex is catastrophic backtracking, see #391
# 매 praise
praise: nice extraction of the retry helper
매 결정 기준
상황
Approach
<200 LOC, single concern
merge as-is
>400 LOC
split into stacked PRs
WIP, want early feedback
draft PR
breaking change
explicit BREAKING CHANGE footer + RFC 먼저
hot fix
small PR, fast-track review, label hotfix
cosmetic only
label chore, rubber-stamp review
기본값: 매 small (<300 LOC), single-purpose, conventional commit title, draft 시작 → ready when CI green → squash-merge.