# 스택된 풀 리퀘스트

GitHub에서 스택된 pull request가 작동하는 방식에 대한 규칙 및 요구 사항입니다.

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

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

> \[!NOTE]
>
> * 스택형 풀 리퀘스트를 사용하려면 모든 브랜치가 동일한 리포지토리에 있어야 합니다. 교차 포크 스택은 지원되지 않습니다.
> * 누적 끌어오기 요청은 .에서 GitHub Desktop지원되지 않습니다.

## 스택형 풀 리퀘스트 가용성

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

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

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

## 스택된 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 최적화](/ko/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests)을 참조하세요.

## 재배정

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

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

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

## 병합 요구 사항

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

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

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

> \[!NOTE] 누적 풀 리퀘스트는 **바이패스 규칙**을 사용한 병합을 지원하지만 맨 아래 풀 리퀘스트만 이런 방식으로 병합할 수 있습니다. 바이패스 규칙을 사용해 전체 스택을 병합할 수 없습니다.
> [리포지토리에 대한 규칙 세트 만들기](/ko/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#granting-bypass-permissions-for-your-branch-or-tag-ruleset)을(를) 참조하세요.

## 병합 메서드

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

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

## 병합 큐를 통한 병합

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

> \[!NOTE]
> 스택을 함께 유지하기 위해 병합 큐는 병합 그룹이 구성된 최대 크기를 최대 50%까지 초과하도록 허용합니다. 스택이 너무 커서 해당 버퍼에 맞지 않으면 자동으로 다음 병합 그룹에 단일 단위로 배치됩니다.

## 선형 히스토리

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

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

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

지침은 [스택형 풀 리퀘스트 관리](/ko/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests#rebasing-your-stack)을(를) 참조하세요.

## 추가 읽기

* [조직에 누적 끌어오기 요청 롤아웃](/ko/pull-requests/tutorials/roll-out-stacked-prs)