GitHub Stacked PR 정식 출시 후 큰 변경을 나눠 검토해보세요

어떤 변경을 쌓아서 검토하면 좋나요?

자료형 추가, 서버 처리, 화면 반영이 차례로 필요한 작업을 예로 들어 볼게요. 각 단계가 바로 아래 단계에 의존하도록 나눌 수 있어요. 구조를 설명하려고 만든 예시이고, GitHub의 특정 저장소 결과는 아니에요.

리뷰어에게는 각 PR이 해결하는 문제와 위아래 의존성을 적어 주세요. 변경을 줄 수만으로 쪼개면 한 층의 의미가 흐려져요. 독립적으로 설명할 수 있는 책임이 분할 기준이에요.

기능	10월 6일 공식 안내의 범위
승인 유지	기반 브랜치가 앞서가도 내용이 변하지 않은 스택을 rebase하면 승인 유지
서명	rebase 때 GitHub가 서명된 대체 커밋 생성
병합 큐	스택을 하나의 병합 그룹으로 처리
기반 브랜치 삭제	스택의 대상 브랜치를 자동 조정
CLI	gh stack 확장에 Git worktree 지원

확인일 2026-10-10, 출처는 GitHub Changelog예요. 승인 유지에는 변경 내용이 그대로라는 조건이 붙어요. 코드를 수정한 경우까지 리뷰가 필요 없어졌다고 읽으면 안 돼요.

GitHub는 스택 병합을 더 일관되게 처리하고, merge commit 방식에서는 PR마다 병합 커밋 하나를 만든다고 설명해요. 팀이 기대하는 이력 형태와 CI의 실행 단위가 맞는지 작은 변경으로 먼저 확인해 보세요.

자동 병합은 발표일 기준으로 이후 몇 주에 걸쳐 제공될 예정이에요. 정식 출시라는 말만 보고 모든 저장소에 자동 병합까지 적용됐다고 가정하면 안 돼요.

공식 안내는 github.com의 모든 요금제에서 제공한다고 밝혀요. GitHub Enterprise Server는 향후 릴리스에 포함될 예정이라, 회사 서버를 쓴다면 설치한 버전의 지원 여부부터 확인하세요.

첫 도입은 영향이 작은 변경으로 하세요. 각 층의 테스트, 보호 규칙, 리뷰 상태, 병합 후 전체 동작을 확인한 다음 범위를 넓히면 돼요.

그럴 필요는 없어요. 서로 의존하는 변경을 작은 검토 단위로 나눌 때 맞는 기능이에요.

공식 안내의 승인 유지 조건은 기반 브랜치가 앞서간 뒤 rebase한 스택의 코드가 그 외에는 바뀌지 않은 경우예요. 코드를 수정했다면 이 조건에 해당하지 않아요.

10월 6일 발표는 향후 Enterprise Server 릴리스에 포함된다고 안내해요. 설치한 버전의 지원 여부를 확인하세요.

모든 자료는 제조사·판매처가 공개한 내용을 확인한 것이며, 확인 이후 달라졌을 수 있습니다.