병합 큐 관리

리포지토리에서 끌어오기 요청에 대한 병합 큐를 사용하여 개발 속도를 높일 수 있습니다.

누가 이 기능을 사용할 수 있나요?

People with admin permissions can manage merge queues for pull requests targeting selected branches of a repository.

Pull request 통합 큐는 GitHub Enterprise Server의 조직 소유 리포지토리에서 사용할 수 있습니다.

이 문서의 내용

병합 큐 정보

병합 큐는 끌어오기 요청 병합을 사용 중인 분기로 자동화하고 호환되지 않는 변경으로 분기가 중단되지 않도록 하여 속도를 높이는 데 도움이 됩니다.

병합 큐는 분기 보호를 병합하기 전에 분기를 최신 상태로 유지하도록 요구하는 것과 동일한 이점을 제공하지만 끌어오기 요청 작성자가 끌어오기 요청 분기를 업데이트하고 병합을 시도하기 전에 상태 검사 완료될 때까지 기다릴 필요는 없습니다.

병합 큐를 사용하는 것은 매일 다양한 사용자로부터 병합되는 끌어오기 요청 수가 비교적 많은 분기에서 특히 유용합니다.

끌어오기 요청이 필요한 모든 분기 보호 검사를 통과한 후 리포지토리에 대한 쓰기 액세스 권한이 있는 사용자가 해당 끌어오기 요청을 큐에 추가할 수 있습니다. 병합 큐는 대상 분기의 최신 버전 및 큐에 이미 있는 끌어오기 요청에 적용할 때 끌어오기 요청의 변경 내용이 필요한 모든 상태 확인을 통과하도록 보장합니다.

병합 큐는 GitHub Actions 또는 사용자 고유의 CI 공급자를 사용하여 병합 큐의 끌어오기 요청에 필요한 검사를 실행할 수 있습니다. 자세한 내용은 "GitHub Actions 설명서"을(를) 참조하세요.

병합 큐를 사용한 끌어오기 요청 병합에 대한 자세한 내용은 병합 큐와 끌어오기 요청 병합"을(를) 참조하세요.

병합 큐에 대한 연속 통합(CI) 워크플로 구성

참고:

  • 분기 이름 패턴에 와일드카드 문자(*)를 사용하는 분기 보호 규칙으로 병합 큐를 사용하도록 설정할 수는 없습니다.
  • 병합 큐는 병합을 계속하기 전에 필요한 검사가 보고될 때까지 기다립니다. 병합 큐를 요구하는 경우 병합 그룹 이벤트를 트리거하고 보고하도록 CI 구성을 업데이트해야 합니다.
  • 병합 큐 및 끌어오기 요청 검사는 분기 보호 규칙 또는 규칙 세트에 따라 결합되고 구성됩니다. 자세한 내용은 "병합 큐 관리"을(를) 참조하세요.

GitHub Actions으로 병합 그룹 검사 트리거

끌어오기 요청이 병합 그룹에 추가되면 merge_group 이벤트를 사용하여 GitHub Actions 워크플로를 트리거해야 합니다.

참고: 리포지토리에서 GitHub Actions을(를) 사용하여 필요한 검사 를 수행하거나 리포지토리의 끌어오기 요청에 대한 조직 규칙 세트 을(를) 통해 워크플로가 필요한 경우 merge_group 이벤트를 추가 트리거로 포함하도록 워크플로를 업데이트해야 합니다. 그렇지 않으면 병합 큐에 끌어오기 요청을 추가할 때 상태 검사가 트리거되지 않습니다. 상태 확인 필요가 보고되지 않으므로 병합이 실패합니다. merge_group 이벤트는 pull_request 및 push 이벤트트와 별개입니다.

대상 분기의 보호에 필요한 검사를 보고하는 워크플로는 다음과 같습니다.

on:
  pull_request:
  merge_group:

merge_group 이벤트의 자세한 내용은 "워크플로를 트리거하는 이벤트"을(를) 참조하세요.

제3자 CI 공급자를 사용하여 병합 그룹 검사 트리거

제3자 CI 공급자를 사용하면 특수 접두사 gh-readonly-queue/{base_branch}(으)로 시작하는 분기가 푸시될 때 실행되도록 CI 구성을 업데이트해야 합니다. 이는 병합 큐에 따라 사용자를 대신하여 생성되고 끌어오기 요청의 sha와 다른 분기가 포함되는 임시 분기입니다.

병합 큐 관리

리포지토리 관리자는 기본 분기에 대한 보호 규칙에서 분기 보호 설정 “병합 큐 필요”를 사용하도록 설정하여 병합 큐를 요구할 수 있습니다. 자세한 내용은 "분기 보호 규칙 관리"을(를) 참조하세요.

"병합 큐 필요" 설정을 활성화하면 다음 설정에도 액세스할 수 있습니다.

  • 병합 방법: 대기 중인 끌어오기 요청을 병합할 때 사용할 방법(병합, 다시 지정 또는 스쿼시)을 선택합니다.

  • 빌드 동시성: 디스패치할 merge_group 웹후크의 최대 수(1 및 100 사이)로, 동시 CI 빌드의 총량을 조절합니다. 이는 병합 큐가 완료할 수 있는 병합의 속도에 영향을 미칩니다.

  • 실패하지 않는 끌어오기 요청만 병합: 이 설정은 병합 큐가 병합할 끌어오기 요청의 그룹을 구성하는 방법을 결정합니다.

    사용 여부설명
    예모든 끌어오기 요청은 병합하는 데 필요한 검사를 충족해야 합니다.
    아니요필요한 검사가 실패한 끌어오기 요청은 필요한 검사를 통과한 그룹에 마지막 끌어오기 요청을 추가할 수 있습니다. 그룹의 마지막 끌어오기 요청이 필요한 검사를 통과한 경우, 이는 병합 그룹의 결합된 변경 집합와 관련하여 검사를 통과했음을 의미합니다. 일시적 테스트 실패가 있지만 거짓 음성이 큐를 유지하지 않도록 하려면 이 확인란을 선택하지 않은 상태로 두는 것이 유용할 수 있습니다.

  • 상태 검사 시간 제한: 검사가 실패했다고 가정하기 전에 큐가 CI의 응답을 기다려야 하는 시간을 선택합니다.

  • 병합 제한: 동시에 베이스 분기(1 및 100 사이)에서 병합할 끌어오기 요청의 최소 및 최대 수를 선택하고, 큐가 더 많은 항목을 기다리지 않도록 중지하고, 최소 수보다 적은 수로 병합해야 하는 시간 제한을 선택합니다.

참고: 병합 제한은 merge_group 빌드를 결합하지 않습니다. 병합 제한은 하나 이상의 merge_group이 빌드 검사를 충족할 때 베이스 분기 병합에만 영향을 줍니다.

병합 한도사용 사례
병합할 최대 끌어오기 요청최대 그룹 크기를 지정할 수 있습니다. 이 크기는 기본 분기에 병합하여 배포를 트리거하고 한 번에 너무 많은 변경 내용을 배포하지 않도록 하는 경우에 유용합니다.
병합할 최소 끌어오기 요청최소 그룹 크기를 지정할 수 있습니다. 이 크기는 기본 분기에 병합하여 긴 CI 빌드 또는 배포 프로세스를 트리거하고, 큐에 다음 항목을 보류하지 않으려는 경우에 유용합니다.
대기 시간최소 그룹 크기에 도달하는 시간에 대한 시간 제한을 지정할 수 있습니다. 그러면 지정된 제한 시간 내에 더 이상 큐에 대기 중인 PR이 없는 경우 더 작은 그룹이 병합될 수 있습니다.

병합 큐의 작동 방식

끌어오기 요청이 병합 큐에 추가되면 병합 큐는 필요한 검사가 항상 충족되는 선입 선출로 병합되도록 합니다.

병합 큐는 특수 접두사가 있는 임시 분기를 만들어 끌어오기 요청 변경 내용의 유효성을 검사합니다. 끌어오기 요청이 병합 큐에 추가되면 끌어오기 요청의 변경 내용이 최신 버전의 base_branch 및 큐에서 앞에 있는 끌어오기 요청의 변경 내용과 함께 merge_group(으)로 그룹화됩니다. GitHub Enterprise Server은(는) base_branch의 분기 보호에 필요한 검사에 통과한 후 모든 변경 내용을 base_branch에 병합합니다.

병합 메서드에 대한 자세한 내용은 "끌어오기 요청 병합 정보"을(를) 참조하세요.

성공적인 CI

여러 끌어오기 요청이 병합 큐에 추가되고 임시 merge_group 분기에서 CI 결과가 성공하면 모두 병합됩니다. 다음 시나리오에서는 두 개의 끌어오기 요청이 큐에 성공적으로 추가되고 대상 분기에 병합됩니다.

  1. 사용자가 병합 큐에 끌어오기 요청 #1을 추가합니다.
  2. 병합 큐는 대상 분기 및 끌어오기 요청 #1의 코드 변경 내용을 포함하는 main/pr-1 접두사가 있는 임시 분기를 만듭니다. 형식 checks_requested의 merge_group 웹후크 이벤트가 디스패치되고 병합 큐가 CI 공급자의 응답을 기다립니다.
  3. 사용자가 병합 큐에 끌어오기 요청 #2을 추가합니다.
  4. 병합 큐는 대상 분기의 코드 변경 내용, 끌어오기 요청 #1 및 끌어오기 요청 #2를 포함하는 main/pr-2 접두사가 있는 임시 분기를 만들고 웹후크를 디스패치합니다.
  5. GitHub Enterprise Server API가 merge_group 분기 main/pr-1 및 main/pr-2에 대한 성공적인 CI 응답을 수신하면 임시 분기 main/pr-2가 대상 분기에 병합됩니다. 이제 대상 분기에 끌어오기 요청 #1 및 #2의 변경 내용이 모두 포함됩니다.

실패한 CI

대상 분기의 최신 버전 및 그 전에 발생한 변경으로 끌어오기 요청을 그룹화하고 큐에서 변경한 후 필수 상태 검사에 실패하거나 기본 분기와 충돌하는 경우 끌어오기 요청이 큐에서 제거됩니다. 끌어오기 요청 타임라인은 끌어오기 요청이 큐에서 제거된 이유를 표시합니다.

다음 시나리오에서는 CI가 하나의 끌어오기 요청에 대해 실패한 상태를 보고할 때 발생하는 일을 간략하게 설명합니다.

  1. 사용자가 병합 큐에 끌어오기 요청 #1을 추가합니다.
  2. 병합 큐는 대상 분기 및 끌어오기 요청 #1의 코드 변경 내용을 포함하는 main/pr-1 접두사가 있는 임시 분기를 만듭니다. 형식 checks_requested의 merge_group 웹후크 이벤트가 디스패치되고 병합 큐가 CI 공급자의 응답을 기다립니다.
  3. 사용자가 병합 큐에 끌어오기 요청 #2을 추가합니다.
  4. 병합 큐는 대상 분기의 코드 변경 내용, 끌어오기 요청 #1 및 끌어오기 요청 #2를 포함하는 main/pr-2 접두사가 있는 임시 분기를 만들고 웹후크를 디스패치합니다.
  5. GitHub Enterprise Server API가 main/pr-1에 대한 실패한 상태를 수신하면 병합 큐는 병합 큐에서 끌어오기 요청 #1을 자동으로 제거합니다.
  6. 병합 큐는 대상 분기 및 끌어오기 요청 #2의 변경 내용만 포함하는 main/pr-2의 접두사를 사용하여 임시 분기를 다시 만듭니다.
  7. GitHub Enterprise Server API가 merge_group 분기 main/pr-2에 대한 성공적인 CI 응답을 수신하면 끌어오기 요청 #1이 포함되지 않고 임시 분기 main/pr-2이(가) 대상 분기에 병합됩니다.

병합 큐에서 끌어오기 요청을 제거할 수 있는 여러 가지 이유가 있습니다.

  • 구성된 CI 서비스가 병합 그룹에 대한 테스트 실패 보고
  • 구성된 시간 제한 설정을 기반으로 성공적인 CI 결과를 기다리는 동안 시간 초과
  • API 또는 병합 큐 인터페이스를 통해 제거를 요청하는 사용자
  • 자동으로 해결할 수 없는 분기 보호 오류

큐의 맨 위로 이동

병합 큐에 끌어오기 요청을 추가할 때 끌어오기 요청을 큐의 맨 위로 이동하는 옵션이 제공됩니다.

참고: 큐의 순서를 변경하면 커밋 그래프에서 중단이 발생하므로 병합 큐의 맨 위로 이동하면 진행 중인 모든 끌어오기 요청이 완전히 다시 빌드됩니다. 이 기능을 많이 활용하면 대상 분기에 대한 병합 속도가 느려질 수 있습니다.

다음 시나리오에서는 사용자가 큐를 이동할 때 발생하는 현상을 간략하게 설명합니다.

  1. 사용자가 병합 큐에 끌어오기 요청 #1을 추가합니다.
  2. 병합 큐는 대상 분기 및 끌어오기 요청 #1의 코드 변경 내용을 포함하는 main/pr-1 접두사가 있는 임시 분기를 만듭니다. 형식 checks_requested의 merge_group 웹후크 이벤트가 디스패치되고 병합 큐가 CI 공급자의 응답을 기다립니다.
  3. 사용자가 병합 큐에 끌어오기 요청 #2을 추가합니다.
  4. 병합 큐는 대상 분기의 코드 변경 내용, 끌어오기 요청 #1 및 끌어오기 요청 #2를 포함하는 main/pr-2 접두사가 있는 임시 분기를 만들고 웹후크를 디스패치합니다.
  5. 사용자가 커밋 그래프에서 중단을 유발하는 이동 옵션을 사용하여 병합 큐에 끌어오기 요청 #3을 추가합니다.
  6. 병합 큐는 대상 분기 및 끌어오기 요청 #3의 코드 변경 내용이 포함된 main/pr-3의 접두사가 있는 임시 분기를 만들고 웹후크를 디스패치합니다.
  7. 병합 큐는 끌어오기 요청 #3의 변경 내용을 포함하는 main/pr-1 및 main/pr-2의 접두사가 있는 임시 분기를 다시 만들고 웹후크를 디스패치합니다.

추가 참고 자료