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

누적 끌어오기 요청을 사용하면 개발자가 큰 변경 내용을 서로 빌드하는 작은 포커스가 있는 끌어오기 요청 체인으로 분할하여 각 계층을 보다 쉽게 검토, 병합 및 배송할 수 있습니다. 누적 끌어오기 요청을 통해 개발자는 검토가 완료될 때까지 기다리지 않고 한 작업을 완료하고 다음 작업으로 바로 이동할 수 있습니다. 이는 팀이 큰 릴리스에서 작업하고 모든 변경 내용이 마지막에 빌드될 때 일반적으로 발생하는 작업에 따라 자연스럽게 달라질 때 가장 중요합니다.

이 자습서에서는 배포 고려 사항 검토, 분기 보호 규칙 및 CI가 스택에서 작동하는 방식 이해 및 팀 시작과 같은 누적 끌어오기 요청에 대한 조직을 준비하는 방법을 안내합니다. 누적 끌어오기 요청에 대한 기본적인 이해는 누적 끌어오기 요청 정보을 참조하세요.

사전 요구 사항

팀에서 이미 끌어오기 요청을 사용하고 있는 경우 누적 끌어오기 요청을 사용하도록 설정됩니다. 이 자습서의 다른 모든 항목은 선택 사항이지만 조직에 다음이 있다고 가정합니다.

• GitHub CLI확장이 gh-stack 설치되어 있습니다. CLI 확장은 스택을 만들고 관리하는 가장 포괄적인 방법입니다.
• 기본 분기에 대해 구성된 분기 보호 규칙입니다.
• GitHub Actions 기본 분기를 대상으로 하는 끌어오기 요청에서 실행되는 워크플로입니다.

Copilot 는 누적 끌어오기 요청을 사용할 필요는 없지만 AI에서 생성된 변경 내용을 누적하려는 팀에 권장됩니다. 누적 끌어오기 요청은 제공된 에이전트 기술을 사용하여 Claude Code 및 Codex와 같은 다른 AI 코딩 에이전트에서도 작동합니다. 끌어오기 요청에 AI 생성 코드 스택을(를) 참조하세요.

1. 출시 고려 사항 검토

팀에 누적 끌어오기 요청을 도입하기 전에 모든 사용자가 무엇을 기대해야 하는지 알 수 있도록 다음 고려 사항을 검토합니다.

스택은 선형이어야 하며 포크를 포함할 수 없습니다.

스택의 모든 끌어오기 요청은 동일한 리포지토리의 일부여야 하며 단일 선형 분기 체인에 빌드되어야 합니다. 분기 구조가 있는 스택 또는 포크에서 끌어오기 요청은 지원되지 않습니다. 팀이 기여를 위해 포크를 사용하는 경우 해당 기여를 현재 스택 외부에 유지하도록 계획합니다.

스택 순서를 다시 지정하려면 GitHub CLI

팀이 스택에서 끌어오기 요청의 순서를 다시 지정해야 하는 경우 확장에서 gh stackGitHub CLI 사용해야 gh stack modify 합니다. 웹 사이트에서 스택을 다시 정렬할 수 있는 GitHub 방법은 없습니다. CLI를 로컬로 사용하지 않는 팀은 스택 순서를 신중하게 미리 계획하거나 이 작업에 대한 확장을 설치해야 합니다.

완료된 스택을 확장할 수 없습니다.

스택의 모든 끌어오기 요청이 병합되면 해당 스택이 닫힙니다. 팀이 맨 위에 새 분기를 추가하고 실행하는 gh stack submit경우 CLI는 동일한 기본 분기를 사용하여 새 스택을 시작합니다. 스택에서 계속 작업하려는 팀은 모든 작업이 완료될 때까지 스택을 열어 두도록 계획해야 합니다.

2. 분기 보호 규칙 및 CI가 스택에서 작동하는 방식 이해

누적 끌어오기 요청은 다른 끌어오기 요청과 동일한 방식으로 기존 규칙을 적용하도록 설계되었지만 스택의 모든 끌어오기 요청이 예상과 약간 다르게 평가되기 때문에 방법을 이해하는 것이 좋습니다.

스택의 모든 끌어오기 요청은 맨 아래 요청뿐만 아니라 직접 대상으로 하는 분기에 대한 것이 아니라 스택의 기준 (일반적으로 main)에 대해 평가됩니다. 이는 다음을 의미합니다.

• 필요한 검토, 필수 상태 검사 및 CODEOWNERS는 스택의 모든 끌어오기 요청에 대해 스택의 기본 분기에 적용됩니다.
• 대상 이벤트를 트리거 pull_request 하는 main 워크플로는 GitHub Actions 스택의 모든 끌어오기 요청에 대해 실행되므로 기존 CI 구성을 변경할 필요가 없습니다.
• 스택 메타데이터는 누적 끌어오기 요청에 대해 워크플로 동작을 특별히 사용자 지정하려는 경우 워크플로 식 github.event.pull_request.stack에서 사용할 수 있습니다. 워크플로는 스택에서 끌어오기 요청당 한 번 실행되므로 팀은 이 메타데이터를 사용하여 중복 실행 시 비용이 많이 드는 작업을 건너뛰고 CI 사용량을 줄일 수 있습니다. 세부 정보는 누적 끌어오기 요청에 대한 CI 최적화(을)를 참조하세요.

필요에 따라 표준 규칙 집합 및 필요한 검사가 있는 리포지토리에 대해 작은 테스트 스택을 열고 다음을 확인하여 이 작업을 확인할 수 있습니다.

1. 검토 및 상태 검사는 아래쪽 요청뿐만 아니라 스택의 모든 끌어오기 요청에 필요합니다.
2. CI 워크플로는 스택의 모든 끌어오기 요청에서 실행됩니다.
3. 병합하려는 스택의 끌어오기 요청과 병합 아래의 모든 항목이 요구 사항을 충족할 때까지 병합이 차단됩니다.

규칙 및 요구 사항의 전체 목록은 누적 끌어오기 요청을 참조하세요.

3. 팀 시작

롤아웃 고려 사항을 검토하고 규칙 및 CI가 스택에서 작동하는 방식을 이해한 후에는 팀이 누적 끌어오기 🥞 요청을 가리키도록 하여 누적 끌어오기 요청을 만들고, 검토하고, 병합하는 데 필요한 모든 것을 결합합니다.

4. 프로그래밍 방식 도구 업데이트

조직에서 누적 끌어오기 요청을 채택할 때 프로그래밍 방식으로 끌어오기 요청을 생성, 병합 또는 추적하는 사내 도구, 봇 또는 대시보드를 검토하고 스택을 고려하도록 업데이트합니다.

대시보드, 봇 또는 내부 도구와 같이 프로그래밍 방식으로 스택 작업을 추적할 수도 있습니다.

• REST API: API에서 반환되는 모든 끌어오기 요청에는 스택의 수, 크기, 끌어오기 요청의 위치 및 스택의 기본 분기를 보여 주는 개체가 스택에 속할 때 포함 stack 됩니다. 전용 스택 API(GET /repos/{owner}/{repo}/stacks)는 리포지토리의 모든 스택 또는 지정된 끌어오기 요청을 포함하는 특정 스택도 나열합니다. REST 및 GraphQL API의 누적 끌어오기 요청을(를) 참조하세요.
• 웹후크: 끌어오기 요청이 pull_request 스택에 속할 때마다 웹후크 페이로드에 동일한 stack 개체가 포함됩니다. 끌어오기 요청이 스택에 처음 추가되면 전용 stacked 작업이 실행되므로 스택이 형성되는 순간에 반응할 수 있습니다.

두 경우 stack 모두 필드는 null 독립 실행형 끌어오기 요청용이므로 스택을 기대하지 않는 기존 통합은 변경되지 않고 계속 작동합니다.