분기 보호 규칙 정보
분기 보호 규칙을 만들면 협력자가 분기에 끌어오기 요청 병합을 포함하여 리포지토리의 분기에 대한 변경 내용을 푸시하기 전에 특정 워크플로 또는 요구 사항을 적용할 수 있습니다. 리포지토리가 조직에 속한 경우에만 바이패스 목록에 행위자를 추가할 수 있습니다.
기본적으로 각 분기 보호 규칙은 일치하는 분기에 대한 강제 푸시를 사용하지 않도록 설정하고 일치하는 분기가 삭제되지 않도록 합니다. 필요에 따라 이 제한을 사용하지 않도록 설정하고 추가 분기 보호 설정을 사용하도록 설정할 수 있습니다.
기본적으로 분기 보호 규칙의 제한 사항은 리포지토리에 대한 관리자 권한이 있는 사람이나 “분기 보호 무시” 권한이 있는 사용자 지정 역할에 적용되지 않습니다. 필요에 따라 “분기 보호 무시” 권한이 있는 관리자 및 역할에 제한을 적용할 수도 있습니다. 자세한 내용은 조직의 사용자 지정 리포지토리 역할 관리을(를) 참조하세요.
특정 분기, 모든 분기 또는 fnmatch 구문으로 지정한 이름 패턴과 일치하는 모든 분기에 대한 분기 보호 규칙을 리포지토리에 만들 수 있습니다. 예를 들어 release 단어를 포함하는 모든 분기를 보호하려면 *release*에 대한 분기 규칙을 만들 수 있습니다. 분기 이름 패턴에 대한 자세한 내용은 분기 보호 규칙 관리을(를) 참조하세요.
모든 병합 요구 사항이 충족되면 자동으로 병합하도록 끌어오기 요청을 구성할 수 있습니다. 자세한 내용은 "끌어오기 요청 자동 병합"을(를) 참조하세요.
Note
한 번에 하나의 분기 보호 규칙만 적용할 수 있습니다. 즉, 여러 버전의 규칙이 동일한 분기를 대상으로 할 경우 어느 규칙이 적용되는지 알기 어려울 수 있습니다. 또한, 조직의 여러 리포지토리에 적용되는 단일 규칙 집합을 만들 수 있습니다. 분기 보호 규칙의 대안에 대한 자세한 내용은 규칙 세트 정보을(를) 참조하세요.
분기 보호 설정 정보
각 분기 보호 규칙에 대해 다음 설정을 사용하거나 사용하지 않도록 지정할 수 있습니다.
- 병합 전 끌어오기 요청 검토 필요
- 병합 전 상태 검사 필요
- 병합 전 대화 확인 필요
- 서명된 커밋 필요
- 선형 기록 필요
- 병합 큐 필요
- 병합 전 배포 성공 필요
- 분기 잠금
- 위 설정 무시를 허용 안 함
- 일치하는 분기에 푸시할 수 있는 사용자 제한
- 강제 푸시 허용
- 삭제 허용
분기 보호를 설정하는 방법에 대한 자세한 내용은 분기 보호 규칙 관리을(를) 참조하세요.
병합 전 끌어오기 요청 검토 필요
리포지토리 관리자 또는 "리포지토리 규칙 편집" 권한이 있는 사용자 지정 역할은 누군가가 끌어오기 요청을 보호된 분기에 병합하기 전에 모든 끌어오기 요청이 특정 수의 승인 검토를 받도록 요구할 수 있습니다. 리포지토리에서 쓰기 권한이 있는 사람 또는 지정된 코드 소유자의 승인 검토를 요청할 수 있습니다.
필요한 검토를 사용하도록 설정하면 협력자는 쓰기 권한이 있는 검토자가 필요한 인원수만큼 승인한 끌어오기 요청을 통해서만 보호된 분기에 대한 변경 내용을 푸시할 수 있습니다.
관리자 권한이 있는 사용자가 검토에서 변경 요청 옵션을 선택하는 경우 끌어오기 요청을 먼저 승인해야 병합할 수 있습니다. 끌어오기 요청의 변경을 요청하는 검토자를 사용할 수 없는 경우 리포지토리에 대한 쓰기 권한이 있는 모든 사용자가 차단하는 검토를 해제할 수 있습니다.
모든 필수 검토자가 끌어오기 요청을 승인한 후에도 보류 중이거나 거부된 검토가 있는 동일한 커밋을 가리키는 헤드 분기가 있는 다른 열린 끌어오기 요청이 있는 경우 협력자는 끌어오기 요청을 병합할 수 없습니다. 쓰기 권한이 있는 사용자는 먼저 다른 끌어오기 요청에 대한 차단 검토를 승인하거나 해제해야 합니다.
검토가 보류 중이거나 거부된 끌어오기 요청을 보호된 분기에 병합하려고 하는 협력자는 오류 메시지를 받게 됩니다.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes have been requested.
필요에 따라 풀 요청의 diff에 영향을 미치는 커밋이 푸시될 때 부실 풀 요청 승인을 해제하도록 선택할 수 있습니다. GitHub은(는) 끌어오기 요청이 승인된 시점에 Diff의 상태를 기록합니다. 이 상태는 검토자가 승인한 일련의 변경 내용을 나타냅니다. Diff가 이 상태에서 변경되는 경우(예: 기여자가 끌어오기 요청 분기에 새 변경 내용을 푸시하거나 업데이트 분기를 클릭하거나 관련 끌어오기 요청이 대상 분기에 병합되기 때문에) 승인 검토가 부실로 해제되고 다른 사용자가 작업을 다시 승인할 때까지 끌어오기 요청을 병합할 수 없습니다. 기본 분기 대한 자세한 내용은 끌어오기 요청 정보을(를) 참조하세요.
필요에 따라 끌어오기 요청 검토를 해제하는 기능을 특정 사용자 또는 팀으로 제한할 수 있습니다. 자세한 내용은 끌어오기 요청 검토 해제을(를) 참조하세요.
필요에 따라 코드 소유자의 검토를 요구할 수 있습니다. 이렇게 하면 코드 소유자가 있는 코드에 영향을 주는 끌어오기 요청은 해당 코드 소유자가 먼저 승인해야 보호된 분기에 병합할 수 있습니다.
필요에 따라 검토 가능한 가장 최근의 푸시를 푸시한 당사자 이외의 사람이 승인하도록 요구할 수 있습니다. 즉, 하나 이상의 다른 권한 있는 검토자가 변경 내용을 승인했습니다. 예를 들어 "마지막 검토자"는 최신 변경 세트가 다른 검토의 피드백을 통합하고 검토되지 않은 새 콘텐츠를 추가하지 않는다는 것을 검사할 수 있습니다.
많은 검토가 필요한 복잡한 끌어오기 요청의 경우, 마지막으로 푸시한 사람이 아닌 다른 사람의 승인을 요구하는 것은 모든 부실 검토를 해제할 필요가 없는 타협이 될 수 있습니다. 이 옵션을 사용하면 "부실" 검토가 해제되지 않으며, 가장 최근에 변경한 사람이 아닌 다른 사람이 승인하는 한 끌어오기 요청이 승인된 상태를 유지합니다. 끌어오기 요청을 이미 검토한 사용자는 이 요구 사항을 충족하기 위해 가장 최근의 푸시 후에 다시 승인할 수 있습니다. 끌어오기 요청이 "하이재킹"(승인되지 않은 콘텐츠가 승인된 끌어오기 요청에 추가됨)될 것이 우려되는 경우 부실 검토를 해제하는 것이 더 안전합니다.
Note
새 커밋이 푸시될 때 부실 끌어오기 요청 승인 해제 및/또는 최신 검토 가능한 푸시의 승인 필요를 선택하는 경우, 끌어오기 요청에 대한 병합 커밋을 수동으로 만들어 보호된 분기에 직접 푸시하면 병합 내용이 끌어오기 요청의 GitHub에서 생성된 병합과 정확히 일치하지 않는 한 실패합니다.
또한 이러한 설정을 사용하면 검토가 제출된 후 병합 기반에 새 변경 내용이 도입되면 승인 검토가 부실로 기각됩니다. 병합 기반은 토픽 분기와 기본 분기 간의 마지막 공통 상위 항목인 커밋입니다. 병합 기반이 변경되면 다른 사용자가 작업을 다시 승인할 때까지 끌어오기 요청을 병합할 수 없습니다.
병합 전 상태 검사 필요
상태 확인 필요는 협력자가 보호된 분기를 변경하기 전에 필요한 모든 CI 테스트를 통과했거나 건너뛰었는지 확인합니다. 필수 상태 검사는 검사 또는 상태일 수 있습니다. 자세한 내용은 상태 검사 정보을(를) 참조하세요.
커밋 상태 API를 사용하여 외부 서비스에서 커밋을 적절한 상태로 표시할 수 있습니다. 자세한 내용은 커밋 상태에 대한 REST API 엔드포인트을(를) 참조하세요.
필수 상태 검사를 사용하도록 설정한 후에는 협력자가 변경 내용을 보호된 분기에 병합하기 전에 모든 필수 상태 검사를 통과해야 합니다. 모든 필수 상태 검사가 통과되면 커밋을 다른 분기로 푸시한 다음 병합하거나 보호된 분기에 직접 푸시해야 합니다.
리포지토리에 대한 쓰기 권한이 있는 모든 사용자 또는 통합은 리포지토리에서 상태 검사의 상태를 설정할 수 있지만, 경우에 따라 특정 GitHub App의 상태 검사만 수락해야 할 수 있습니다. 필수 상태 검사를 추가할 때 최근에 이 검사를 예상 상태 업데이트 원본으로 설정한 앱을 선택할 수 있습니다. 다른 사용자 또는 통합이 상태를 설정하면 병합이 허용되지 않습니다. "모든 원본"을 선택하면 병합 상자에 나열된 각 상태의 작성자를 수동으로 확인할 수 있습니다.
필수 상태 검사를 "loose" 또는 "strict"로 설정할 수 있습니다. 선택한 필수 상태 검사의 유형은 분기를 병합하기 전에 기본 분기의 최신 상태로 업데이트해야 하는지 여부를 결정합니다.
| 필수 상태 검사 유형 | 설정 | 병합 요구 사항 | 고려 사항 |
|---|---|---|---|
| 엄격 | 병합 전 분기 업데이트 필요 확인란을 선택합니다. | 분기를 병합하기 전에 반드시 기본 분기의 최신 상태로 업데이트해야 합니다. | 이는 필수 상태 검사의 기본 동작입니다. 다른 협력자가 대상 분기에 업데이트한 후 헤드 분기를 최신 상태로 만들어야 하므로 더 많은 빌드가 필요할 수 있습니다. |
| Loose | 병합 전 분기 업데이트 필요 확인란을 선택하지 않습니다. | 분기를 병합하기 전에 기본 분기의 최신 상태로 업데이트할 필요가 없습니다. | 다른 협력자가 끌어오기 요청을 병합한 후 헤드 분기를 최신 상태로 만들 필요가 없으므로 필요한 빌드 수가 줄어듭니다. 기본 분기와 호환되지 않는 변경 내용이 있는 경우 분기를 병합한 후 상태 검사가 실패할 수 있습니다. |
| 사용 안 함 | 병합 전 상태 확인 통과 필요 확인란을 선택하지 않습니다. | 분기에 병합 제한이 없습니다. | 필수 상태 검사를 사용하도록 설정하지 않은 경우 협력자는 기본 분기의 최신 상태인지 관계없이 언제든지 분기를 병합할 수 있습니다. 이렇게 하면 호환되지 않는 변경이 발생할 가능성이 증가합니다. |
문제 해결 정보는 필수 상태 검사 문제 해결을(를) 참조하세요.
병합 전 대화 확인 필요
끌어오기 요청을 보호된 분기에 병합하기 전에 댓글을 모두 확인해야 합니다. 이렇게 하면 병합하기 전에 모든 댓글이 처리 또는 확인됩니다.
서명된 커밋 필요
분기에서 필수 커밋 서명을 사용하도록 설정하면 기여자 은 서명되고 확인된 커밋만 분기에 푸시할 수 있습니다. 자세한 내용은 커밋 서명 확인 정보을(를) 참조하세요.
Note
협력자가 커밋 서명이 필요한 분기에 서명되지 않은 커밋을 푸시하는 경우 협력자는 확인된 서명을 포함하도록 커밋을 다시 지정한 다음 다시 작성된 커밋을 분기로 강제 푸시해야 합니다.
커밋이 서명되고 확인된 경우 항상 로컬 커밋을 분기에 푸시할 수 있습니다. 그러나 끌어오기 요청을 GitHub Enterprise Server의 분기에 병합할 수는 없습니다. 끌어오기 요청을 로컬로 병합할 수 있습니다. 자세한 내용은 로컬에서 끌어오기 요청 체크 아웃을(를) 참조하세요.
선형 기록 필요
선형 커밋 기록을 적용하면 협력자가 병합 커밋을 분기에 푸시할 수 없습니다. 즉, 보호된 분기에 병합된 끌어오기 요청은 Squash 병합 또는 다시 지정 병합을 사용해야 합니다. 엄격한 선형 커밋 기록을 사용하면 팀이 변경 내용을 보다 쉽게 되돌릴 수 있습니다. 메서드에 대한 자세한 내용은 끌어오기 요청 병합 정보을(를) 참조하세요.
선형 커밋 기록을 요구하려면 먼저 리포지토리에서 Squash 병합 또는 다시 지정 병합을 허용해야 합니다. 자세한 내용은 끌어오기 요청 병합 구성을(를) 참조하세요.
병합 큐 필요
병합 큐는 끌어오기 요청 병합을 사용 중인 분기로 자동화하고 호환되지 않는 변경으로 분기가 중단되지 않도록 하여 속도를 높이는 데 도움이 됩니다.
병합 큐는 분기 보호를 병합하기 전에 분기를 최신 상태로 유지하도록 요구하는 것과 동일한 이점을 제공하지만 끌어오기 요청 작성자가 끌어오기 요청 분기를 업데이트하고 병합을 시도하기 전에 상태 검사 완료될 때까지 기다릴 필요는 없습니다.
병합 큐를 사용하는 것은 매일 다양한 사용자로부터 병합되는 끌어오기 요청 수가 비교적 많은 분기에서 특히 유용합니다.
끌어오기 요청이 필요한 모든 분기 보호 검사를 통과한 후 리포지토리에 대한 쓰기 액세스 권한이 있는 사용자가 해당 끌어오기 요청을 큐에 추가할 수 있습니다. 병합 큐는 대상 분기의 최신 버전 및 큐에 이미 있는 끌어오기 요청에 적용할 때 끌어오기 요청의 변경 내용이 필요한 모든 상태 확인을 통과하도록 보장합니다.
병합 큐는 GitHub Actions 또는 사용자 고유의 CI 공급자를 사용하여 병합 큐의 끌어오기 요청에 필요한 검사를 실행할 수 있습니다. 자세한 내용은 "GitHub Actions 설명서"을(를) 참조하세요.
GitHub Enterprise Server는 모든 필수 CI 검사에 통과하면 분기 보호에 구성된 병합 전략에 따라 끌어오기 요청을 병합합니다. 병합 큐에 대한 자세한 내용은 "병합 큐 관리"을 참조하십시오.
병합 전 배포 성공 필요
분기를 병합하기 전에 변경 내용을 특정 환경에 성공적으로 배포하도록 요구할 수 있습니다. 예를 들어 이 규칙을 사용하여 변경 내용을 기본 분기에 병합하기 전에 변경 내용이 스테이징 환경에 성공적으로 배포되도록 할 수 있습니다.
분기 잠금
분기를 잠그면 분기가 읽기 전용이 되며 분기에 대한 커밋을 수행할 수 없습니다. 잠긴 분기도 삭제할 수 없습니다.
기본적으로 포크된 리포지토리는 업스트림 리포지토리와의 동기화를 지원하지 않습니다. 포크 동기화 허용을 사용하도록 설정하여 업스트림 리포지토리에서 변경 내용을 끌어오면서 포크의 분기에 대한 다른 기여를 방지할 수 있습니다.
위 설정 무시를 허용 안 함
기본적으로 분기 보호 규칙의 제한 사항은 리포지토리에 대한 관리자 권한이 있는 사람이나 리포지토리의 “분기 보호 무시 권한”이 있는 사용자 지정 역할에 적용되지 않습니다.
이 설정을 사용하면 “분기 보호 무시” 권한이 있는 관리자 및 역할에도 제한을 적용할 수도 있습니다. 자세한 내용은 조직의 사용자 지정 리포지토리 역할 관리을(를) 참조하세요.
일치하는 분기에 푸시할 수 있는 사용자 제한
분기 제한을 사용하도록 설정하면 권한이 부여된 사용자, 팀 또는 앱만 보호된 분기로 푸시할 수 있습니다. 보호된 분기의 설정에서 보호된 분기에 대한 푸시 액세스 권한이 있는 사용자, 팀 또는 앱을 보고 편집할 수 있습니다. 상태 검사가 필요한 경우 필수 검사가 실패하면 보호된 분기에 푸시할 수 있는 권한이 있는 사용자, 팀 및 앱도 분기에 병합되지 않습니다. 보호된 분기에 푸시할 수 있는 권한이 있는 사용자, 팀 및 앱도 끌어오기 요청이 필요하면 끌어오기 요청을 만들어야 합니다.
필요에 따라 규칙과 일치하는 분기 만들기에 동일한 제한을 적용할 수 있습니다. 예를 들어 특정 팀이 단어 release가 포함된 모든 분기로 푸시할 수 있도록 허용하는 규칙을 만드는 경우 해당 팀의 구성원만 단어 release가 포함된 새 분기를 만들 수 있습니다.
보호된 분기에 대한 푸시 액세스 권한만 부여하거나 리포지토리에 대한 쓰기 액세스 권한이 있는 사용자, 팀 또는 설치된 GitHub Apps에 일치하는 분기를 만들 수 있는 권한을 부여할 수 있습니다. 리포지토리에 대한 관리자 권한이 있는 사용자 및 앱은 항상 보호된 분기로 푸시하거나 일치하는 분기를 만들 수 있습니다.
강제 푸시 허용
기본적으로 GitHub Enterprise Server은(는) 모든 보호된 분기에서 강제 푸시를 차단합니다. 보호된 분기에 강제 푸시를 사용하도록 설정하면 강제 푸시할 수 있는 두 그룹 중 하나를 선택할 수 있습니다.
- 관리자 권한이 있는 사용자를 포함하여 리포지토리에 대한 쓰기 권한이 있는 모든 사용자가 분기로 강제 푸시할 수 있도록 허용합니다.
- 특정 사용자 또는 팀만 분기로 강제 푸시할 수 있도록 허용합니다.
누군가가 분기로 강제 푸시하는 경우 강제 푸시는 다른 협력자가 분기 기록에서 제거되는 자신의 작업을 기반으로 하는 커밋을 의미할 수 있습니다. 병합 충돌 또는 손상된 끌어오기 요청이 발생할 수 있습니다. 강제 푸시를 사용하여 분기를 삭제하거나 분기를 통해 끌어오기 요청에서 승인되지 않은 커밋을 가리킬 수도 있습니다.
강제 푸시를 사용하도록 설정해도 다른 분기 보호 규칙은 재정의되지 않습니다. 예를 들어 분기에 선형 커밋 기록이 필요한 경우 해당 분기에 병합 커밋을 강제 푸시할 수 없습니다.
사이트 관리자가 리포지토리의 모든 보호된 분기에서 강제 푸시를 차단한 경우 보호된 분기에 강제 푸시를 사용하도록 설정할 수 없습니다. 자세한 내용은 엔터프라이즈에서 리포지토리 관리 정책 적용을(를) 참조하세요.
사이트 관리자가 기본 분기에만 강제 푸시를 차단한 경우에도 다른 보호된 분기에 대해 강제 푸시를 사용하도록 설정할 수 있습니다.
삭제 허용
기본적으로 보호된 분기는 삭제할 수 없습니다. 보호된 분기 삭제를 사용하도록 설정하면 리포지토리에 대한 쓰기 권한이 있는 모든 사용자가 분기를 삭제할 수 있습니다.
Note
분기가 잠겨 있으면 분기를 삭제할 수 있는 권한이 있더라도 분기를 삭제할 수 없습니다.