누적 끌어오기 요청 정보

누적 끌어오기 요청 정보

누적 끌어오기 요청은 동일한 리포지토리에 있는 두 개 이상의 끌어오기 요청입니다. 여기서는 다음과 같습니다.

• 첫 번째 또는 아래쪽 끌어오기 요청은 스택의 트렁크(일반적으로 리포지토리의 기본 분기) main를 대상으로 하지만 릴리스 분기와 같은 모든 분기일 수 있습니다.
• 각 후속 끌어오기 요청은 아래 끌어오기 요청의 분기를 대상으로 합니다.

   ┌── feat/frontend     → PR #3 (base: feat/api-endpoints)  ← top
  ┌── feat/api-endpoints → PR #2 (base: feat/auth-layer)
 ┌── feat/auth-layer     → PR #1 (base: main)               ← bottom
main (default base branch)

누적 분기는 종속성 체인을 형성하며, 각 분기는 아래 분기에서 빌드됩니다. 공유 형식 및 데이터베이스 스키마와 같은 기본 변경 내용은 하위 분기로 이동하며, API 경로 및 UI 구성 요소와 같이 해당 요소에 의존하는 코드는 더 높은 분기로 이동합니다.

스택의 각 끌어오기 요청은 하나 이상의 커밋에 대한 개별적인 검토 가능한 변경을 나타냅니다. 각 끌어오기 요청을 독립적으로 검토하고 반복할 수 있으며, 각 요청은 해당 계층의 차이와 해당 분기와 그 아래 분기 간의 변경 내용만 표시합니다.

핵심 원칙: 한 계층의 코드가 다른 계층의 코드에 종속된 경우 종속성은 동일한 분기 또는 하위 분기에 있어야 합니다. 지금까지 빌드한 내용에 따라 다른 문제를 시작할 때 새 분기를 만듭니다. 예를 들어 백 엔드에서 프런트 엔드 작업으로 전환할 때 핵심 논리에서 테스트로 이동하거나 현재 분기가 이미 충분히 큰 경우 검토할 수 있습니다.

누적 끌어오기 요청을 사용하는 GitHub 이유

하나의 변경을 완료하고 다음으로 바로 이동

누적 끌어오기 요청을 사용하면 여전히 열려 있는 끌어오기 요청 위에 새 끌어오기 요청을 열 수 있습니다. 대규모 프로젝트 중에 다음 변경 내용은 아직 병합되지 않은 작업에 따라 달라질 수 있습니다. 스택을 사용하여 병합되기를 기다리는 대신 계속 빌드할 수 있습니다.

포커스가 있는 변경 내용이 포함된 스택의 각 끌어오기 요청에서 검토자는 큰 끌어오기 요청 대신 각 계층에 대해 작은 차이(diff)를 볼 수 있습니다. 더 작은 끌어오기 요청은 검토 속도가 빨라지고, 스키밍될 가능성이 적으며, 부실해지고 병합 충돌이 발생할 가능성이 적습니다.

대용량 개발에 적합

AI 에이전트를 사용하여 많은 코드를 한 번에 생성하는 경우 스택은 각 변경 사항을 진행할 수 있는 위치를 제공합니다. 에이전트는 하나의 작업을 완료한 다음, 이를 기반으로 하는 다음 작업을 시작합니다. 해당 시퀀스는 스택에 직접 매핑됩니다. 각 요청은 아래와 같이 작업당 하나의 끌어오기 요청입니다. 스택을 사용하면 관련 없는 변경 내용을 단일 분기에 결합하는 대신 해당 종속성을 명시적으로 기록할 수 있습니다.

에서 누적 끌어오기 요청을 사용할 경우의 이점 GitHub

누적 끌어오기 요청이 없으면 큰 변경 내용이 더 작고 종속적인 끌어오기 요청으로 나누면 추가 작업이 생성됩니다.

• 분기 관리. 종속 끌어오기 요청에서 분기를 재지정하고 동기화 상태로 유지하는 것은 지루하고 오류가 발생하기 쉽습니다.
• 규칙 및 CI. 분기 보호 규칙 및 CI 검사는 종종 체인의 아래쪽 끌어오기 요청에 대해서만 트리거되므로 나머지의 실제 상태를 알기 어렵습니다.
• 컨텍스트를 검토합니다. 스택의 나머지 부분의 컨텍스트에서 단일 변경 내용을 검토하면 검토 품질이 저하됩니다.

누적 끌어오기 요청은 각 계층을 작게 유지하면서 끌어오기 요청 체인을 연결된 단위로 처리하여 이러한 문제를 해결합니다.

재배정

재지정은 스택 작업에서 가장 까다로운 부분이며 GitHub 자동으로 처리합니다. 끌어오기 요청에서 서버 쪽 계단식 재베이스를 트리거하거나 확장을 사용하여 로컬 연계 다시베이스를 gh stack 실행할 수 있습니다 GitHub CLI. 스택 아래쪽에서 끌어오기 요청을 병합하면 나머지 분기가 자동으로 다시 기반이 되어 다음 끌어오기 요청이 기본 기본 분기를 대상으로 합니다.

누적 끌어오기 요청을 사용할 수 있는 위치

누적 끌어오기 요청은 다음에서 사용할 수 있습니다.

• GitHub CLI
• GitHub 웹사이트
• GitHub Mobile
• 웹후크, REST API 및 GraphQL을 통한 프로그래밍 방식 지원
• 에이전트의 경우 기술을 통해 gh-stack

GitHub CLI에서

확장은 gh stackGitHub CLI 로컬 개발 워크플로를 처리합니다. 올바른 종속성 순서로 분기를 만들고 추적하고, 분기를 다시 기반으로 유지하고, 분기를 푸시하고, 끌어오기 요청을 만들고 연결하고, 레이어 간을 탐색할 수 있습니다. 누적 끌어오기 요청 CLI 명령을(를) 참조하세요.

GitHub 웹 사이트에서

끌어오기 요청이 스택의 일부인 경우 다음이 표시됩니다.

• 끌어오기 요청의 맨 위에 있는 스택 아이콘 으로, 보고 있는 레이어를 나타내는 숫자가 있습니다.
• 병합 상자에 스택 맵이 나타납니다. 스택의 모든 끌어오기 요청과 해당 상태를 표시하며 한 번의 클릭으로 모든 계층으로 이동할 수 있습니다. 트렁크(기본 기본 분기)는 아래쪽에 있으며 스택의 각 끌어오기 요청은 아래 끌어오기 요청의 분기를 대상으로 합니다.

웹후크, REST API 및 GraphQL을 통한 프로그래밍 방식 지원

누적 끌어오기 요청은 프로그래밍 방식으로 사용할 수 있으므로 사용자 고유의 도구, 자동화 및 대시보드에 통합할 수 있습니다.

• 웹후크는 이벤트 페이로드에 stack 개체를 포함 pull_request 하므로 끌어오기 요청이 연결되거나 스택 내에서 이동하거나 스택을 떠날 때 자동화가 응답할 수 있습니다.
• REST API는 끌어오기 요청의 스택 멤버 자격을 읽고 스택을 나열, 만들기, 확장 및 디졸브할 엔드포인트를 제공합니다.
• GraphQL API는 스택을 쿼리하기 위한 끌어오기 요청과 끌어오기 요청의 위치에 읽기 전용 stack 필드를 노출합니다.

규칙, CI 및 병합

규칙 및 CI 적용

누적 끌어오기 요청은 워크플로를 지원 GitHub Actions 합니다.

스택의 끌어오기 요청에 대한 병합 요구 사항은 일반적으로 아래쪽 끌어오기 요청의 기본 분기에 의해 결정됩니다 main.

• CODEOWNER 승인과 같은 분기 보호 규칙은 기본 분기를 직접 대상으로 하지 않는 중간 스택 끌어오기 요청도 스택의 모든 끌어오기 요청에 적용됩니다.
• 기본 분기 실행에서 끌어오기 요청에 의해 트리거되는 CI 검사는 맨 아래 요청뿐만 아니라 스택의 모든 끌어오기 요청에 대해 실행됩니다.

이렇게 하면 스택의 모든 레이어가 병합되기 전에 동일한 품질 표시줄을 충족합니다.

병합

전체 스택, 단일 끌어오기 요청 또는 여러 끌어오기 요청에 걸쳐 있는 스택의 일부를 병합할 수 있습니다. 전체 스택은 한 번에 병합할 필요가 없지만 끌어오기 요청은 아래쪽에서 위로 병합해야 합니다.

• 위쪽 끌어오기 요청을 병합하여 전체 스택을 한 번에 병합합니다. 아래의 모든 끌어오기 요청은 함께 제공됩니다.
• 중간 스택 끌어오기 요청을 병합하여 스택의 일부를 병합합니다. 아래의 끌어오기 요청도 병합되고 위의 끌어오기 요청은 열린 상태로 유지되며 스택의 기본 분기를 자동으로 다시 대상으로 지정합니다.

스택은 병합 커밋, 스쿼시 및 재베이스 병합 메서드를 지원하며 병합 큐를 인식합니다. 결과 커밋 기록은 아래에서 시작하여 각 끌어오기 요청을 개별적으로 병합하는 것과 같습니다.

다음 단계

• 누적 끌어오기 요청에 대한 빠른 시작
• 조직에 누적 끌어오기 요청 롤아웃