규칙 세트에 사용 가능한 규칙

분기 또는 태그 규칙 집합을 만들어 사용자가 리포지토리에서 선택한 분기 및 태그와 상호 작용하는 방법을 제어합니다. 프라이빗 또는 내부 리포지토리와 리포지토리의 전체 포크 네트워크에 대한 푸시를 차단하는 푸시 규칙 집합을 만들 수도 있습니다.

규칙 세트를 만들 때 특정 사용자가 규칙 세트의 규칙을 무시하도록 허용할 수 있습니다. 특정 역할, 특정 팀 또는 GitHub Apps을(를) 가진 사용자일 수 있습니다.

푸시 규칙 집합의 경우 바이패스 권한은 리포지토리와 리포지토리의 전체 포크 네트워크에 적용됩니다. 이는 이 리포지토리의 전체 포크 네트워크에 있는 모든 리포지토리에 대해 이 규칙 집합을 바이패스할 수 있는 유일한 사용자는 루트 리포지토리에서 이 규칙 집합을 바이패스할 수 있는 사용자뿐임을 의미합니다.

규칙 집합과 바이패스 권한을 만드는 방법에 대한 자세한 내용은 "리포지토리에 대한 규칙 세트 만들기"을(를) 참조하세요.

만들기 제한

선택하면 바이패스 권한이 있는 사용자만 지정한 패턴과 이름이 일치하는 분기 또는 태그를 만들 수 있습니다.

업데이트 제한

선택하면 바이패스 권한이 있는 사용자만 지정한 패턴과 이름이 일치하는 분기 또는 태그로 푸시할 수 있습니다.

삭제 제한

선택하면 바이패스 권한이 있는 사용자만 지정한 패턴과 이름이 일치하는 분기 또는 태그를 삭제할 수 있습니다. 이 규칙은 기본적으로 선택되어 있습니다.

선형 기록 필요

선형 커밋 기록을 적용하면 협력자가 병합 커밋을 대상 분기 또는 태그에 푸시할 수 없습니다. 즉, 분기 또는 태그에 병합된 끌어오기 요청은 Squash 병합 또는 다시 지정 병합을 사용해야 합니다. 엄격한 선형 커밋 기록을 사용하면 팀이 변경 내용을 보다 쉽게 되돌릴 수 있습니다. 메서드에 대한 자세한 내용은 "끌어오기 요청 병합 정보"을(를) 참조하세요.

선형 커밋 기록을 요구하려면 먼저 리포지토리에서 Squash 병합 또는 다시 지정 병합을 허용해야 합니다. 자세한 내용은 "끌어오기 요청 병합 구성"을(를) 참조하세요.

병합 전 배포 성공 필요

분기를 병합하기 전에 변경 내용을 특정 환경에 성공적으로 배포하도록 요구할 수 있습니다. 예를 들어 이 규칙을 사용하여 변경 내용을 기본 분기에 병합하기 전에 변경 내용이 스테이징 환경에 성공적으로 배포되도록 할 수 있습니다.

서명된 커밋 필요

분기에서 필수 커밋 서명을 사용하도록 설정하면 기여자 와 봇은 서명되고 확인된 커밋만 분기에 푸시할 수 있습니다. 자세한 내용은 "커밋 서명 확인 정보"을(를) 참조하세요.

분기 보호 규칙 및 규칙 집합은 분기를 만들 때 다르게 동작합니다. 규칙 집합을 사용하면 다른 분기에서 액세스할 수 없는 커밋만 검사 반면 분기 보호 규칙을 사용하면 일치하는 분기를 만드는 푸시를 제한하지 않는 한 서명된 커밋을 확인하지 않습니다. 둘 다 분기를 업데이트할 때 다른 분기에서 커밋에 연결할 수 있더라도 지정된 범위의 모든 커밋을 검사합니다.

두 방법 모두 verified_signature?를 사용하여 커밋에 유효한 서명이 있는지 확인합니다. 그렇지 않은 경우 업데이트가 수락되지 않습니다.

Note

커밋이 항상 서명됨을 나타내는 계정 설정의 경계 모드를 사용하도록 설정한 경우 GitHub이(가) "부분적으로 확인됨"으로 식별하는 모든 커밋은 서명된 커밋이 필요한 분기에서 허용됩니다. 경계 모드에 대한 자세한 내용은 "모든 커밋에 대한 확인 상태 표시"을(를) 참조하세요.
협력자가 커밋 서명이 필요한 분기에 서명되지 않은 커밋을 푸시하는 경우 협력자는 확인된 서명을 포함하도록 커밋을 다시 지정한 다음 다시 작성된 커밋을 분기로 강제 푸시해야 합니다.

커밋이 서명되고 확인된 경우 항상 로컬 커밋을 분기에 푸시할 수 있습니다. GitHub에 대한 끌어오기 요청을 사용하여 서명되고 확인된 커밋을 분기에 병합할 수도 있습니다. 그러나 끌어오기 요청의 작성자가 아니면 끌어오기 요청을 GitHub의 분기로 Squash 및 병합할 수 없습니다. 끌어오기 요청을 로컬로 Squash 및 병합할 수 있습니다. 자세한 내용은 "로컬에서 끌어오기 요청 체크 아웃"을(를) 참조하세요.

병합 메서드에 대한 자세한 내용은 "GitHub에서의 병합 메서드 정보"을(를) 참조하세요.

병합 전 끌어오기 요청 필요

대상 분기에 대한 모든 변경 내용을 끌어오기 요청과 연결하도록 요청할 수 있습니다. 끌어오기 요청을 반드시 승인할 필요는 없지만 끌어오기 요청을 열어야 합니다.

추가 설정

Note

새 커밋이 푸시될 때 부실 끌어오기 요청 승인 해제 및/또는 최신 검토 가능한 푸시의 승인 필요를 선택하는 경우, 끌어오기 요청에 대한 병합 커밋을 수동으로 만들어 보호된 분기에 직접 푸시하면 병합 내용이 끌어오기 요청의 GitHub에서 생성된 병합과 정확히 일치하지 않는 한 실패합니다.

또한 이러한 설정을 사용하면 검토가 제출된 후 병합 기반에 새 변경 내용이 도입되면 승인 검토가 부실로 기각됩니다. 병합 기반은 토픽 분기와 기본 분기 간의 마지막 공통 상위 항목인 커밋입니다. 병합 기반이 변경되면 다른 사용자가 작업을 다시 승인할 때까지 끌어오기 요청을 병합할 수 없습니다.

리포지토리 관리자 또는 "리포지토리 규칙 편집" 권한이 있는 사용자 지정 역할은 누군가가 끌어오기 요청을 보호된 분기에 병합하기 전에 모든 끌어오기 요청이 특정 수의 승인 검토를 받도록 요구할 수 있습니다. 리포지토리에서 쓰기 권한이 있는 사람 또는 지정된 코드 소유자의 승인 검토를 요청할 수 있습니다.

필요한 검토를 사용하도록 설정하면 협력자는 쓰기 권한이 있는 검토자가 필요한 인원수만큼 승인한 끌어오기 요청을 통해서만 분기에 대한 변경 내용을 푸시할 수 있습니다.

사용자가 검토에서 변경 요청 옵션을 선택하는 경우 끌어오기 요청을 먼저 승인해야 병합할 수 있습니다. 끌어오기 요청의 변경을 요청하는 검토자를 사용할 수 없는 경우 리포지토리에 대한 쓰기 권한이 있는 모든 사용자가 차단하는 검토를 해제할 수 있습니다.

모든 필수 검토자가 끌어오기 요청을 승인한 후에도 보류 중이거나 거부된 검토가 있는 동일한 커밋을 가리키는 헤드 분기가 있는 다른 열린 끌어오기 요청이 있는 경우 협력자는 끌어오기 요청을 병합할 수 없습니다. 쓰기 권한이 있는 사용자는 먼저 다른 끌어오기 요청에 대한 차단 검토를 승인하거나 해제해야 합니다.

필요에 따라 풀 요청의 Diff에 영향을 미치는 커밋이 푸시될 때 부실 풀 요청 승인을 해제하도록 선택할 수 있습니다. GitHub은(는) 끌어오기 요청이 승인된 시점에 Diff의 상태를 기록합니다. 이 상태는 검토자가 승인한 일련의 변경 내용을 나타냅니다. Diff가 이 상태에서 변경되는 경우(예: 기여자가 끌어오기 요청 분기에 새 변경 내용을 푸시하거나 업데이트 분기를 클릭하거나 관련 끌어오기 요청이 대상 분기에 병합되기 때문에) 승인 검토가 부실로 해제되고 다른 사용자가 작업을 다시 승인할 때까지 끌어오기 요청을 병합할 수 없습니다. 대상 분기에 대한 자세한 내용은 "끌어오기 요청 정보"을(를) 참조하세요.

필요에 따라 코드 소유자의 검토를 요구할 수 있습니다. 이렇게 하면 코드 소유자가 있는 콘텐츠를 수정하는 끌어오기 요청은 해당 코드 소유자가 먼저 승인해야 보호된 분기에 병합할 수 있습니다. 코드 소유자가 여러 명인 경우 코드 소유자 중 누구라도 승인하면 이 요구 사항을 충족할 수 있습니다. 자세한 내용은 "코드 소유자 정보"을(를) 참조하세요.

필요에 따라 끌어오기 요청을 병합하기 전에 분기에 푸시할 마지막 사람이 아닌 다른 사용자의 승인을 요청할 수 있습니다. 즉, 하나 이상의 다른 권한이 있는 검토자가 변경 내용을 승인했습니다. 예를 들어 "마지막 검토자"는 최신 변경 세트가 다른 검토의 피드백을 통합하고 검토되지 않은 새 콘텐츠를 추가하지 않는다는 것을 검사할 수 있습니다.

많은 검토가 필요한 복잡한 끌어오기 요청의 경우, 마지막으로 푸시한 사람이 아닌 다른 사람의 승인을 요구하는 것은 모든 부실 검토를 해제할 필요가 없는 타협이 될 수 있습니다. 이 옵션을 사용하면 "부실" 검토가 해제되지 않으며, 가장 최근에 변경한 사람이 아닌 다른 사람이 승인하는 한 끌어오기 요청이 승인된 상태를 유지합니다. 끌어오기 요청을 이미 검토한 사용자는 이 요구 사항을 충족하기 위해 가장 최근의 푸시 후에 다시 승인할 수 있습니다. 끌어오기 요청이 "하이재킹"(승인되지 않은 콘텐츠가 승인된 끌어오기 요청에 추가됨)될 것이 우려되는 경우 부실 검토를 해제하는 것이 더 안전합니다.

필요에 따라 끌어오기 요청을 분기에 병합하기 전에 댓글을 모두 확인하도록 요청할 수 있습니다. 이렇게 하면 병합하기 전에 모든 댓글이 처리 또는 확인됩니다.

병합 전 상태 검사 통과 요구하기

필수 상태 검사는 협력자가 분기 또는 규칙 세트의 대상 태그를 변경하기 전에 필요한 모든 CI 테스트가 통과되었는지 확인합니다. 필수 상태 검사는 검사 또는 상태일 수 있습니다. 자세한 내용은 "상태 검사 정보"을(를) 참조하세요.

커밋 상태 API를 사용하여 외부 서비스에서 커밋을 적절한 상태로 표시할 수 있습니다. 자세한 내용은 "커밋 상태에 대한 REST API 엔드포인트"을(를) 참조하세요.

필수 상태 검사를 사용하도록 설정한 후에는 협력자가 변경 내용을 분기 또는 태그에 병합하기 전에 모든 필수 상태 검사를 통과해야 합니다.

리포지토리에 대한 쓰기 권한이 있는 모든 사용자 또는 통합은 리포지토리에서 상태 검사의 상태를 설정할 수 있지만, 경우에 따라 특정 GitHub App의 상태 검사만 수락해야 할 수 있습니다. 필수 상태 검사 규칙을 추가할 때 상태 업데이트의 예상 원본으로 앱을 선택할 수 있습니다. 앱은 statuses:write 권한이 있는 리포지토리에 설치되어야 하고, 최근에 검사 실행을 제출해야 하며, 규칙 세트의 기존 필수 상태 검사에 연결해야 합니다. 다른 사용자 또는 통합에서 상태를 설정하면 병합이 허용되지 않습니다. "모든 원본"을 선택하면 병합 상자에 나열된 각 상태의 작성자를 수동으로 확인할 수 있습니다.

필수 상태 검사를 "loose" 또는 "strict"로 간주할 수 있습니다. 선택한 필수 상태 검사의 유형은 분기를 병합하기 전에 기본 분기의 최신 상태로 업데이트해야 하는지 여부를 결정합니다.

필수 상태 검사 유형	설정	병합 요구 사항	고려 사항
엄격	병합 전 분기 업데이트 필요 확인란을 선택합니다.	주제 분기를 병합하기 전에 반드시 기본 분기의 최신 상태로 업데이트해야 합니다.	이는 필수 상태 검사의 기본 동작입니다. 다른 협력자가 대상 분기에 업데이트한 후 헤드 분기를 최신 상태로 만들어야 하므로 더 많은 빌드가 필요할 수 있습니다.
Loose	병합 전 분기 업데이트 필요 확인란을 선택하지 않습니다.	분기를 병합하기 전에 기본 분기의 최신 상태로 업데이트할 필요가 없습니다.	다른 협력자가 끌어오기 요청을 병합한 후 헤드 분기를 최신 상태로 만들 필요가 없으므로 필요한 빌드 수가 줄어듭니다. 기본 분기와 호환되지 않는 변경 내용이 있는 경우 분기를 병합한 후 상태 검사가 실패할 수 있습니다.
사용 안 함	병합 전 상태 확인 통과 필요 확인란을 선택하지 않습니다.	분기에 병합 제한이 없습니다.	필수 상태 검사를 사용하도록 설정하지 않은 경우 협력자는 기본 분기의 최신 상태인지 관계없이 언제든지 분기를 병합할 수 있습니다. 이렇게 하면 호환되지 않는 변경이 발생할 가능성이 증가합니다.

문제 해결 정보는 "필수 상태 검사 문제 해결"을(를) 참조하세요.

code scanning 병합 보호 설정

리포지토리가 code scanning(으)로 구성된 경우 규칙 집합을 사용하여 다음 조건 중 하나가 충족될 때 당겨받기 요청이 병합되지 않도록 할 수 있습니다.

필수 도구가 규칙 집합에 정의된 심각도에 대한 code scanning 경고를 발견했습니다.
필수 code scanning 도구의 분석이 아직 진행 중입니다.
필수 code scanning 도구가 리포지토리에 대해 구성되지 않았습니다.

자세한 내용은 "코드 검사 병합 보호 설정"을(를) 참조하세요. code scanning에 대한 일반적인 정보는 “코드 검사 정보”을(를) 참조하세요.

강제 푸시 차단

사용자가 대상 분기 또는 태그에 강제로 푸시하는 것을 방지할 수 있습니다. 이 규칙은 기본적으로 사용하도록 설정되어 있습니다.

다른 사람이 분기 또는 태그에 강제로 푸시하는 경우, 다른 협력자가 작업을 기반으로 한 커밋은 분기 또는 태그의 기록에서 제거될 수 있습니다. 병합 충돌 또는 손상된 끌어오기 요청으로 이어질 수 있습니다. 강제 푸시를 사용하여 분기를 삭제하거나 분기를 통해 끌어오기 요청에서 승인되지 않은 커밋을 가리킬 수도 있습니다.

강제 푸시를 사용하도록 설정해도 다른 규칙은 재정의되지 않습니다. 예를 들어 분기에 선형 커밋 기록이 필요한 경우 해당 분기에 병합 커밋을 강제 푸시할 수 없습니다.

규칙 세트에 사용 가능한 규칙

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

이 문서의 내용