스택된 풀 리퀘스트

스택은 동일한 리포지토리에 있는 일련의 끌어오기 요청으로, 각 끌어오기 요청이 아래 끌어오기 요청의 분기를 대상으로 하여 단일 분기(일반적으로 주 분기)에 배치되는 순서가 지정된 체인을 형성합니다. 하나의 큰 끌어오기 요청 대신 더 작은 끌어오기 요청 집합을 가져옵니다. 각 끌어오기 요청에는 고유한 포커스가 있는 diff가 있으므로 팀원은 각 계층을 독립적으로 검토하고 승인할 수 있습니다.

스택의 모든 끌어오기 요청은 직접 대상으로 하는 브랜치가 무엇이든 상관없이 스택 의 베이스에 대한 규칙(일반적으로 main인)을 기준으로 평가됩니다. 즉, 중간 스택 풀 리퀘스트에도 아래쪽 풀 리퀘스트와 동일한 기준이 적용됩니다.

스택형 풀 리퀘스트 가용성

gh stack GitHub CLI 확장은 로컬 개발 워크플로를 처리합니다. 올바른 종속성 순서로 분기를 만들고 추적하고, 분기를 다시 기반으로 유지하고, 분기를 푸시하고, 풀 리퀘스트를 만들고 연결하며, 레이어 간을 탐색합니다.

GitHub CLI 가 필요하지 않습니다. 기본 Git 작업은 표준이며 대신 GitHub 웹 사이트에서 스택을 만들 수 있습니다.

Jujutsu 또는 Sapling과 같은 다른 도구를 사용하여 로컬 분기를 관리하고 푸시하는 경우에도 여전히 GitHub CLI 또는 GitHub 웹사이트를 사용하여 해당 분기에서 끌어오기 요청 스택을 열 수 있습니다. 다른 도구를 스택형 풀 리퀘스트와 함께 사용을(를) 참조하세요.

스택된 pull request를 위한 트렁크

스택의 트렁크는 아래쪽 풀 리퀘스트의 기본 분기입니다. 스택의 나머지 모든 pull request는 그 위에 빌드됩니다. 트렁크는 기본적으로 리포지토리의 기본 분기(예: main)로 설정되지만, 릴리스 분기 또는 수명이 긴 기능 분기와 같은 어떤 분기든 될 수 있습니다.

트렁크 설정:

• GitHub CLI에서--base BRANCH 옵션을 gh stack init 명령에 전달하세요(예: gh stack init --base release auth-layer).
• GitHub 웹 사이트에서 원하는 브랜치를 트렁크로 하여 하단 풀 리퀘스트를 만듭니다. 나머지 스택은 이를 기반으로 빌드됩니다.

분기 보호 규칙, 필수 검사 및 CI는 기본 분기뿐만 아니라 스택이 대상으로 하는 트렁크에 대해서도 모두 평가됩니다.

브랜치 보호 및 필수 검사

다음은 각 풀 리퀘스트가 바로 아래에 있는 분기가 아니라 스택 베이스를 대상으로 하는 것처럼 평가됩니다.

규칙	평가 방법
필수 검토	스택 베이스를 기준으로 평가됩니다.
필수 상태 확인	스택 베이스를 기준으로 평가됩니다.
CODEOWNERS (코드 소유자)	스택의 바닥부터 평가됩니다.
CODEOWNERS 하위 풀 리퀘스트에서 변경되지만 위의 풀 리퀘스트에는 영향을 주지 않습니다.
코드 검사 워크플로우	스택 베이스를 기준으로 평가됩니다.

GitHub Actions

GitHub 작업 워크플로는 스택의 각 풀 리퀘스트가 스택의 베이스 브랜치를 대상으로 하는 것처럼 트리거됩니다. pull_request 이벤트를 대상으로 main 실행되도록 구성된 워크플로는 맨 아래 pull request만이 아니라 스택의 각 pull request마다 실행되므로, 워크플로 변경은 필요하지 않습니다.

스택의 기본 분기와 같은 스택 메타데이터는 워크플로 식 github.event.pull_request.stack에서 사용할 수 있습니다. 이 속성은 끌어오기 요청이 스택에 속하는 경우에만 존재합니다.

중복 CI 사용을 줄이기 위한 메타데이터 필드 및 패턴의 전체 집합은 스택형 풀 리퀘스트를 위한 CI 최적화을 참조하세요.

재배정

리베이스를 사용할 수 있거나 필요한 경우 병합 상자는 리베이스 스택 단추를 표시하여 이를 나타냅니다. 예를 들어 끌어오기 요청을 변경하면 스택이 선형이 아닌 경우 이런 일이 발생할 수 있습니다. 아래쪽 풀 리퀘스트가 병합되면 리베이스가 자동으로 수행되며 일반적으로 수동으로 리베이스할 필요가 없습니다.

스택이 리베이스되면 다음을 예상할 수 있습니다.

• 스택을 리베이스하면 서명된 커밋이 생성됩니다.
• diff가 변경되지 않는 경우 스택을 리베이스하는 것은 검토 가능한 새 커밋으로 계산되지 않습니다. 이 경우 새 커밋이 푸시되면 오래된 pull request 승인 해제 규칙이 활성화되어 있어도 승인이 유지됩니다.

병합 요구 사항

스택의 끌어오기 요청이 병합되기 전에 다음 조건이 모두 참이어야 합니다.

• 풀 리퀘스트는 필요한 검토, 필수 상태 검사 및 CODEOWNER 승인을 포함하여 스택 베이스의 모든 분기 보호 요구 사항을 충족합니다.
• 스택에서 그 아래에 있는 모든 풀 리퀘스트도 이러한 요구 사항을 충족합니다.
• 스택에는 분기 간에 완전히 선형적인 히스토리가 있습니다.

예를 들어 스택 main ← PR1 ← PR2 ← PR3에서 PR #3을 병합하려면 PR #1 및 PR #2도 검사를 통과하고, 필수 검토를 받고, 모든 분기 보호 규칙을 충족해야 합니다.

병합 메서드

스택은 세 가지 병합 메서드를 모두 지원합니다. 각 경우에 풀 리퀘스트는 하나의 원자적 작업으로 반영됩니다.

• 병합 커밋은 병합되는 각 끌어오기 요청마다 병합 커밋 하나를 생성하여 각 끌어오기 요청의 전체 커밋 기록을 유지합니다.
• Squash는 끌어오기 요청당 하나의 깨끗한 스쿼시된 커밋을 만듭니다. n 끌어오기 요청을 병합하면 기본 분기에 n 스쿼시된 커밋이 만들어집니다.
• Rebase 는 각 풀 리퀘스트의 커밋을 기본 분기로 재생하여 병합 커밋 없이 선형 기록을 만듭니다.

병합 큐를 통한 병합

스택은 병합 큐를 완전히 지원합니다. 스택의 모든 풀 리퀘스트는 올바른 순서로 큐에 추가됩니다. 끌어오기 요청이 큐에서 제거되거나 제외되면 스택에서 그 위에 있는 끌어오기 요청도 모두 제거됩니다.

선형 히스토리

스택의 모든 분기 간에 완전한 선형 기록은 병합에 대한 엄격한 요구 사항입니다. 변경 내용이 하위 분기로 푸시되거나 트렁크가 앞으로 이동할 때 스택의 선형 기록이 손실될 수 있습니다.

선형 기록을 복원하려면 연속 재베이스를 실행합니다.

• CLI에서 — gh stack rebase를 실행한 다음 gh stack push로 푸시합니다.
• GitHub 웹사이트에서 — 병합 상자에서 리베이스 스택을 클릭하여 서버 측 연쇄 리베이스를 트리거합니다.

지침은 스택형 풀 리퀘스트 관리을(를) 참조하세요.

추가 읽기

• 조직에 누적 끌어오기 요청 롤아웃