GitHub Stacked PRs are now available

URL: https://www.youtube.com/watch?v=kzQzmL2o8vk 날짜: 2026-07-30 채널: GitHub

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

GitHub가 ==Stacked PR(스택형 풀 리퀘스트)== 기능을 정식 출시했다. 작은 기능 하나를 추가하려다 보면 어느새 거대해져 버리는 PR 문제를, 여러 개의 작은 PR을 순서대로 쌓아 올리는 방식으로 해결한다.

• 큰 PR은 리뷰가 느리고, 디버그하기 어렵고, 오해를 낳기 쉽다
• Stacked PR에서는 각 PR이 main이 아니라 바로 아래 브랜치를 대상으로 한다
• 가장 아래 PR만 main으로 향하고, 그 위에 다음 PR이, 또 그 위에 다음 PR이 쌓이는 구조다

블로그 예시를 통해 게시글 → 스타일링 → 댓글 기능을 세 개의 PR로 층층이 쌓아 올리는 과정을 시연하고, 리뷰어가 PR을 하나씩 머지하거나 스택 전체를 한 번에 머지할 수 있다는 점을 보여준다.

---

1. Stacked PR이 필요한 이유 — 작은 변경이 거대한 PR로 불어나는 문제

1.1. 문제 상황: PR이 점점 커지는 흔한 패턴

1. 작은 기능 추가에서 시작

   1. 최초 의도: "기능 하나만 추가하자"는 생각으로 작업을 시작한다
   2. 근처 버그 발견 후 수정: 작업 중 근처에서 버그를 발견하면 그것도 함께 고치게 된다
   3. UI 개선까지 추가: UI를 더 낫게 보이려고 몇 가지 개선사항을 더 얹으면서, 작은 변경이 순식간에 거대한 PR로 불어난다

2. 큰 PR의 부작용

   1. 느린 리뷰: 큰 PR은 리뷰하는 데 시간이 더 오래 걸린다
   2. 디버그의 어려움: 문제가 생겼을 때 어디서 발생했는지 추적하기 어렵다
   3. 오해 유발: 여러 변경사항이 뒤섞여 있어 리뷰어와 작성자 사이에 오해가 생기기 쉽다

1.2. Stacked PR의 구조

1. 기존 방식과의 차이

   1. 기존 방식: 모든 브랜치가 각자 main을 대상으로 한다
   2. Stacked PR 방식: 각 PR이 main이 아니라 바로 아래 브랜치를 대상으로 한다

2. 레이어 구조

   1. 맨 아래 PR: main으로 향한다
   2. 다음 PR들: 바로 아래 PR 위에 순차적으로 쌓인다

---

2. 실전 데모 — 블로그를 세 개의 PR로 층층이 쌓아 만들기

블로그를 게시글, 스타일링, 댓글이라는 세 개의 깔끔한 레이어로 만드는 과정을 실제로 시연한다.

2.1. 첫 번째 레이어 — 게시글 PR

1. 터미널에서 시작

   1. 브랜치 생성과 커밋: 브랜치를 만들고 첫 게시글을 커밋한다
   2. 한 명령어로 스택의 맨 아래 PR 열기: 명령어 하나로 스택의 기초가 되는 첫 PR을 연다

2. 토대가 되는 첫 PR

   1. 기초 벽돌에 비유: 이 첫 PR은 다른 모든 것이 그 위에 쌓이는 토대이며, "첫 번째 벽돌을 쌓는 것"에 비유한다
   2. main에서 바로 분기: PR 1번은 main에서 곧바로 브랜치가 갈라져 나온다는 점을 짚는다
   3. 결과물: 평범한 첫 게시글이 나오는데, 아직 보기 좋지는 않지만 정상 작동한다

2.2. 두 번째 레이어 — 스타일링 PR

1. 첫 PR 머지를 기다리지 않고 계속 작업

   1. main이 아닌 이전 PR 위에 스택: 두 번째 PR은 main이 아니라 다른(첫 번째) PR 바로 위에 쌓인다
   2. 병렬 작업 가능: 첫 번째 PR이 머지되기를 기다리지 않고도 계속 빌드해나갈 수 있다

2. 결과: 블로그에 스타일링을 추가하는 두 번째 레이어로, 결과물이 이미 훨씬 나아 보인다

2.3. 세 번째 레이어 — 댓글 섹션 PR

1. 한 층 더 쌓기: 댓글 섹션이 다시 그 위에 스택으로 쌓인다
2. 최종 결과: 세 개의 PR, 세 개의 브랜치가 하나의 스택으로 모두 연결된 상태가 된다

2.4. GitHub에서 스택 전체 확인 및 머지

1. 스택 전체를 한눈에 확인

   1. 머지 준비 완료 상태: GitHub에서 머지할 준비가 된 스택 전체를 확인할 수 있다
   2. 완성된 블로그: 게시글, 스타일, 댓글이 조각조각 쌓여 완성된 블로그를 확인할 수 있다

2. 유연한 머지 옵션

   1. 하나씩 머지: 리뷰어는 PR을 하나씩 머지할 수 있다
   2. 스택 전체를 한 번에 머지: 또는 스택 전체를 한 번에 머지할 수도 있다

---

주요 발언 모음

"Large PRs are slower to review, harder to debug, and oftentimes lead to more misunderstanding."

"With Stacked PRs, each pull request targets the branch right below it instead of every branch targeting main."

"This first PR is the foundation everything else builds on. Think of it like layering the first brick."

"I can keep building without waiting for the first one to merge."

"Smaller PRs foster reviews and better code."

핵심 데이터 & 수치

• 데모 구성: 블로그를 게시글(Post) → 스타일링(Styling) → 댓글(Comments) 세 개의 PR로 나눠 시연한다.
• 머지 방식: PR을 하나씩 개별적으로 머지하거나, 스택 전체를 한 번에 머지하는 두 가지 옵션을 제공한다.
• 명령어 기반 워크플로: 터미널에서 브랜치 생성, 커밋, 스택 맨 아래 PR 열기까지 명령어 하나로 처리한다.

결론 및 시사점

1. GitHub Stacked PR은 하나의 큰 기능을 작은 단위(레이어)로 쪼개 순차적으로 쌓아 올리는 워크플로를 공식 지원한다.
2. 각 PR이 main이 아니라 바로 아래 PR을 대상으로 하기 때문에, 이전 PR의 머지를 기다리지 않고도 다음 작업을 계속 진행할 수 있다.
3. 리뷰어 입장에서는 작은 단위로 PR을 검토할 수 있어 리뷰 속도와 코드 품질이 함께 개선된다.
4. 머지 시점에는 PR을 개별적으로 머지하거나 스택 전체를 한 번에 머지하는 유연성을 제공한다.
5. "기능 하나만 추가하려다 거대한 PR이 되어버리는" 흔한 문제를, 처음부터 레이어 단위로 설계하는 습관으로 예방할 수 있음을 시사한다.