GitHub 스택 PR, 리베이스해도 리뷰 승인이 유지되는 조건

main이 앞서가도 코드 차이가 그대로라면 승인을 남긴다

리뷰를 끝낸 여러 PR을 쌓아 둔 사이 main에 다른 변경이 들어왔을 때, 스택 전체를 리베이스한다는 이유만으로 같은 코드를 다시 승인할 필요는 없다. GitHub의 10월 6일 정식 출시 발표는 기준 브랜치를 따라 갱신하되 코드가 그대로인 스택에서 Rebase stack이 승인을 유지한다고 설명한다. 새 커밋이 올라오면 오래된 승인을 해제하는 설정을 켠 저장소도 포함한다.

조건은 리뷰 대상 코드 차이(diff)가 바뀌지 않는 것이다. 따라서 리베이스와 함께 기능을 수정하거나 충돌을 해결하면서 코드를 바꾼 경우까지 승인 유지 대상으로 묶을 수는 없다. 커밋이 새로 만들어졌는지와 리뷰했던 변경 내용이 달라졌는지를 구분해야 한다.

의존 관계를 그대로 두고 리뷰할 크기만 줄인다

스택 PR은 같은 저장소의 PR을 순서대로 연결한다. 첫 PR이 main을 대상으로 하고, 다음 PR은 첫 PR의 브랜치를 대상으로 하는 식이다. 각 리뷰 화면에는 해당 단계에서 추가한 변경이 보인다.

예를 들어 공통 자료형, 이를 쓰는 API, API를 호출하는 화면을 차례로 만든다면 아래처럼 나눌 수 있다. 이는 기능을 분할하는 예시이며, 모든 프로젝트에 적용할 고정 순서는 아니다.

하위 작업이 병합되기를 기다리는 동안 상위 작업을 진행할 수 있다. 맨 아래 PR이 병합되면 GitHub가 남은 브랜치를 자동으로 리베이스한다. 한 PR에 전부 넣지 않아도 변경 사이의 의존 관계를 유지할 수 있는 이유다.

리뷰 승인이 남아 있어도 하위 PR의 실패를 건너뛸 수는 없다

스택의 병합 조건은 선택한 PR 하나에만 적용되지 않는다. 병합할 PR과 그 아래의 모든 PR이 스택 기준 브랜치의 필수 리뷰·검사·CODEOWNERS 조건을 만족해야 하며, 브랜치 사이 이력도 선형이어야 한다. PR 3을 승인했다고 테스트에 실패한 PR 2를 건너뛰고 함께 병합할 수는 없다.

규칙의 기준 역시 바로 아래 브랜치가 아니라 스택 전체가 최종적으로 들어갈 브랜치다. main이 기준이면 중간 PR에도 main의 규칙이 적용된다. main 대상 pull_request 이벤트로 설정한 GitHub Actions도 스택의 각 PR에서 실행된다.

리뷰 설정도 구별해야 한다. 브랜치 보호 문서는 변경된 diff의 오래된 승인을 해제하는 옵션과, 마지막으로 검토 가능한 push를 한 사람 외의 승인을 요구하는 옵션을 나눠 설명한다. 승인 표시만 보지 말고 병합 영역에서 어떤 조건이 아직 충족되지 않았는지 읽어야 한다.

리베이스는 스택 단위로, 확인은 변경 내용과 검사 상태별로 한다

웹의 Rebase stack 버튼이나 GitHub CLI의 gh stack 확장으로 브랜치를 다시 정렬할 수 있다. 확장을 사용하는 로컬 작업의 명령은 gh stack rebase 뒤 gh stack push다. 정식 출시에서는 서버의 스택 리베이스가 만드는 대체 커밋에 서명도 추가됐다.

팀의 확인 순서는 diff가 실제로 바뀌었는지, 선택한 PR 아래에 실패한 검사나 부족한 리뷰가 있는지, 마지막 push에 관한 별도 승인 조건이 남아 있는지로 잡을 수 있다. 새 코드를 검토하는 규칙을 끄는 대신, 이미 검토한 코드의 승인과 새로 충족해야 할 병합 조건을 구별하는 편이 낫다.

자주 묻는 질문