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

누적 끌어오기 요청을 통해 개발자는 큰 변경 내용을 서로 빌드하는 작고 집중적인 끌어오기 요청 체인으로 분할할 수 있습니다. 이 접근 방식은 개발자가 다른 코딩 에이전트를 포함하여 Copilot 더 많은 코드를 생성함에 따라 조직에서 검토 품질을 유지하는 데 도움이 될 수 있습니다.

누적 끌어오기 요청에는 설치 또는 사용이 필요하지 않습니다. 팀에서 이미 끌어오기 요청을 사용하는 경우 현재 스택을 만들 수 있습니다. 아래 단계는 기능을 켜지 않고 기존 컨트롤을 준비하고 원활한 롤아웃을 지원하는 데 도움이 됩니다.

이 자습서는 누적 끌어오기 요청이 조직에 적합한지 여부를 결정하고, 기초가 올바른지 확인하고, 워크플로를 파일럿하고, 채택을 지원하고, 프로그래밍 방식 도구를 업데이트하는 데 도움이 됩니다. 누적 끌어오기 요청에 대한 기본적인 이해는 누적 끌어오기 요청 정보을 참조하세요.

1. 누적 끌어오기 요청이 적합한지 결정

롤아웃에 투자하기 전에 이 빠른 자체 검사를 사용합니다.

• 팀이 자체 또는 다른 코딩 에이전트와 함께 Copilot 대량의 코드를 생성합니까?
• 팀이 독립적인 끌어오기 요청으로 분할하기 어려운 큰 기능, 특히 모노레포 내부에서 작업합니까?

팀을 설명하는 경우 누적된 끌어오기 요청은 작업이 하나의 제약 조건에 맞는 한 각 끌어오기 요청이 병합될 때까지 기다리지 않고 더 작은 단위로 종속 변경 내용을 제출하는 데 도움이 될 수 있습니다. 스택의 모든 끌어오기 요청은 하나의 선형 분기 체인에 따라 동일한 리포지토리에 있어야 합니다. 스택은 포크 또는 분기 구조를 포함할 수 없으므로 기여를 위해 포크에 크게 의존하는 팀은 당분간 이러한 기여를 스택 외부에 유지해야 합니다.

2. 기초가 제자리에 있는지 확인

스택의 각 끌어오기 요청은 직접 대상으로 하는 분기가 아니라 스택의 기준 (일반적으로 main)에 대해 평가됩니다. 기존 분기 보호 규칙 또는 규칙 집합 및 CI 워크플로는 자동으로 적용됩니다.

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

고려해야 할 한 가지 선택적 추가 사항: 개발자가 스택을 디졸브하지 않고 만든 후 끌어오기 요청의 순서를 다시 지정해야 하는 경우 확장을 gh stack채택 GitHub CLI 합니다. 현재 위치 다시 정렬을 수행하려면 gh stack modifyGitHub 웹 사이트에서 개발자가 끌어오기 요청을 제거하고 원하는 순서로 스택을 다시 만들어야 합니다.

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

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

3. 소규모 그룹이 있는 파일럿

자체 또는 통해 또는 다른 코딩 에이전트를 통해 Copilot 대량의 코드를 생성하는 소규모 개발자 그룹을 선택합니다. 일회용 예제 대신 파일럿에 대한 실제 대표 기능을 사용하도록 그룹에 요청합니다.

첫 번째 스택을 만들려면 사용자를 누적 끌어오기 요청에 대한 빠른 시작로 안내합니다. 파일럿 후 개발자 및 검토자로부터 다음 사항에 대한 피드백을 수집합니다.

• 스택 계획이 기존 워크플로에 적합한 방법 및 개발자가 현재 위치 다시 정렬이 필요한지 여부(확장 필요 gh stack )
• 스택의 모든 끌어오기 요청이 자체적으로 필요한 검토 및 상태 검사를 수행하여 검토 흐름이 다르게 느껴졌는지 여부
• 해당 지원 또는 문서 간 격차

4. 채택 롤아웃 및 지원

파일럿 후에는 팀과 스택 만들기, 검토, 관리 및 병합에 대한 일상적인 지침을 공유합니다. 누적 끌어오기 요청.

2단계에서 설명한 대로 개발자가 스택을 gh stackGitHub CLI 용해하지 않고 순서를 다시 지정해야 하는 경우 확장을 권장합니다. 로컬 CLI 도구를 사용하지 않는 팀은 웹 사이트에서 원하는 순서 GitHub 로 스택을 제거하고 다시 만들 수 있습니다.

1단계의 맞춤 신호 중 하나인 대량의 AI 생성 코드를 생성하는 팀은 끌어오기 요청에 AI 생성 코드 스택에서 코딩 에이전트의 변경 내용을 쌓는 방법에 대한 지침을 찾을 수 있습니다.

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

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

조직에서 내부 CLI 또는 기타 개발자 도구를 제공하는 경우 Stacks API를 사용하여 개발자가 채택 gh stack하도록 요구하는 대신 스택 만들기 및 관리를 기존 도구에 통합할 수 있습니다.

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

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

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