GitHub stacked PR GA: 작은 diff와 독립적으로 배포 가능한 변경은 다르다

큰 변경을 세 PR로 나누면 리뷰 화면은 짧아집니다. 하지만 위쪽 PR이 아래쪽 변경에 의존한다면, 화면이 짧다는 사실만으로 각 PR을 독립적으로 배포할 수 있는 것은 아닙니다.

10월 6일 공개된 기능과 남은 운영 질문

GitHub는 2026년 10월 6일 stacked pull requests의 일반 공개를 발표했습니다. 작은 PR을 각각 리뷰하고 함께 병합하는 흐름을 제공하며 github.com의 모든 플랜에서 이용할 수 있다고 밝혔습니다.

이번 발표에서 스택은 merge queue에 하나의 merge group으로 들어갑니다. 반면 merge commit 방식에서는 PR마다 merge commit을 만듭니다. 테스트 그룹과 커밋 기록의 단위가 같다고 가정하지 마세요.

예를 들어 A는 공용 함수, B는 그 함수를 쓰는 API, C는 UI라고 합시다. 각 설명에 자기 변경과 의존 PR을 적고, 리뷰어가 비교할 base를 명시합니다. 이 예시는 권장 작업 설계이며 제품의 자동 보장 기능이 아닙니다.

B의 화면만 읽으면 A에 포함된 권한 검사 누락을 놓칠 수 있습니다. 리뷰 체크리스트를 해당 diff의 로직 검토와 A+B+C 통합 동작 검토로 나누고, 최종 조합을 누가 확인할지 정하세요.

GitHub는 코드가 그대로인 스택을 base 변경 뒤 rebase할 때 승인을 유지한다고 설명합니다. stale approval을 해제하는 저장소에서도 이 동작이 적용됩니다. 승인 표시와 현재 통합 결과의 검증은 별도로 읽어야 합니다.

작은 팀은 rebase 전후의 commit SHA와 테스트한 merge group을 기록할 수 있습니다. 테스트가 재실행됐는지, 로그가 어떤 조합을 가리키는지 확인한 뒤 병합합니다. 초록 체크의 색만 복사해 릴리스 근거로 삼지 마세요.

공용 함수와 API가 같이 있어야 동작하는 변경이라면 배포 계획에도 그 의존성을 남깁니다. PR별 commit이 존재해도 임의의 한 commit만 되돌리면 나머지 호출자가 깨질 수 있으므로 rollback 조합을 미리 검토합니다.

독립적인 버그 수정까지 억지로 스택으로 묶을 필요는 없습니다. 순서가 필요한 변경에는 스택이 유용하지만, 관련 없는 작업을 묶으면 한 PR의 검증 지연이 전체 검토를 기다리게 만들 수 있습니다. 이는 팀 운영상의 판단입니다.

GitHub는 auto-merge를 향후 몇 주에 걸쳐 배포한다고 밝혔습니다. GA라는 제목만 보고 오늘 모든 계정에서 같은 자동 병합 버튼이 있다고 문서화하지 말고, 실제 저장소에서 보이는 기능을 확인하세요.

공식 발표는 preview 피드백에 따라 탐색과 자동화가 개선됐다고 설명합니다. 이것은 관심 신호이지만 특정 팀의 생산성이 오른다는 보장은 아닙니다. 우리 팀에서는 리뷰 대기와 통합 실패를 직접 측정하는 편이 낫습니다.

도입 첫 주에는 함수·호출자처럼 의존 관계가 명확한 두 PR을 고릅니다. 각 PR에 base·의존성·검증 명령을 적고, 통합 테스트 책임자와 rollback 범위를 합의한 뒤 한 번 병합해 보세요.

리뷰 시간이 줄었는지와 통합 실패가 늘었는지를 함께 봅니다. 스택을 유지하는 비용이 더 크면 일반 PR로 돌아갈 수 있습니다. 팀에 맞는 기준은 diff 개수보다 검토와 배포에서 실제로 줄어든 혼란입니다.

발표는 10월 6일, 이 글의 확인일은 2026년 10월 8일입니다. 저장소 규칙과 실제 가용 기능을 확인한 뒤 도입하세요.