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

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

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

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

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

생성 제한

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

업데이트 제한

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

삭제 제한

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

선형 커밋 기록을 적용하면 협력자가 병합 커밋을 대상 분기 또는 태그에 푸시할 수 없습니다. 다시 말해, 분기나 태그에 병합되는 모든 끌어오기 요청은 스쿼시 병합 또는 리베이스 병합을 통해 처리되어야 합니다. 엄격한 선형 커밋 기록을 사용하면 팀이 변경 내용을 보다 쉽게 되돌릴 수 있습니다. 메서드 병합 방법에 대한 자세한 내용은 풀 리퀘스트 병합에 대한 정보을(를) 참조하세요.

선형 커밋 기록을 요구하려면 먼저 저장소에서 스쿼시 병합 또는 리베이스 병합을 허용해야 합니다. 자세한 내용은 끌어오기 요청 병합 구성을(를) 참조하세요.

배포가 성공적으로 완료되어야 병합 가능합니다.

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

서명된 커밋 필요

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

분기 보호 규칙 및 규칙 집합은 분기를 만들 때 다르게 동작합니다. 규칙 집합을 사용하면 다른 분기에서 액세스할 수 없는 커밋만 검사 반면 분기 보호 규칙을 사용하면 일치하는 분기를 만드는 푸시를 제한하지 않는 한 서명된 커밋을 확인하지 않습니다. 두 명령어 모두 지정된 범위 내 모든 커밋을 검사하며, 분기 업데이트 시 다른 분기의 커밋을 참조할 수 있는 경우에도 마찬가지입니다.

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

참고

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

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

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

병합 전 끌어오기 요청 필요

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

추가 설정

참고

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

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

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

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

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

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

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

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

필요한 경우, 해당 브랜치에 마지막으로 푸시한 사용자가 아닌 다른 팀원의 승인을 받은 후 풀 리퀘스트를 병합할 수 있습니다. 즉, 하나 이상의 다른 권한이 있는 검토자가 변경 내용을 승인했습니다. 예를 들어 "마지막 검토자"는 최신 변경 세트가 다른 검토의 피드백을 통합하고 검토되지 않은 새 콘텐츠를 추가하지 않는다는 것을 검사할 수 있습니다.

많은 검토가 필요한 복잡한 끌어오기 요청의 경우, 마지막으로 푸시한 사람이 아닌 다른 사람의 승인을 요구하는 것은 모든 부실 검토를 해제할 필요가 없는 타협이 될 수 있습니다. 이 옵션을 사용하면 "부실" 검토가 해제되지 않으며, 가장 최근에 변경한 사람이 아닌 다른 사람이 승인하는 한 끌어오기 요청이 승인된 상태를 유지합니다. 끌어오기 요청을 이미 검토한 사용자는 이 요구 사항을 충족하기 위해 가장 최근의 푸시 후에 다시 승인할 수 있습니다. 승인된 풀 리퀘스트가 ‘하이재킹’되어 허가되지 않은 내용이 포함되는 위험을 방지하기 위해서는, 기존 검토 결과를 자동으로 초기화하도록 설정하는 것이 보안 측면에서 더욱 안전합니다.

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

필요에 따라 병합, 스쿼시, 리베이스의 병합 형식을 요구할 수 있습니다. 이는 대상 분기가 허용된 종류에 따라서만 병합될 수 있음을 의미합니다. 또한 리포지토리에서 병합 방법을 비활성화하고 규칙 집합에 다른 방법이 필요한 경우에는 병합이 차단됩니다. GitHub 병합 메서드 정보을(를) 참조하세요.

필수 검토자

필요에 따라 끌어오기 요청이 특정 파일 또는 디렉터리를 변경하는 경우 특정 팀의 검토 또는 승인을 요구할 수 있습니다. 최대 15개의 팀을 지정할 수 있으며, 각 팀에 대해 팀 구성원의 일정 수의 승인을 요구할 수 있습니다.

          **검토자** 드롭다운을 사용하면 규칙이 정의되는 범위에 있는 모든 팀을 선택할 수 있습니다.

* 조직 전체 규칙: 팀은 조직에 속해야 합니다. * 리포지토리 수준 규칙: 팀은 리포지토리를 소유한 조직에 속해야 합니다.

이 규칙은 팀이 포함되지 않으므로 사용자 소유 리포지토리에서 사용할 수 없습니다.

필수 승인은 0에서 10으로 설정할 수 있습니다. 승인 값이 0으로 설정되면 팀은 가시성 확보를 위해 포함되지만, 별도의 승인 절차를 거칠 필요는 없습니다.

각 팀에 대해 설정이 적용되는 파일을 결정하는 파일 패턴 목록을 지정할 수 있습니다. 이 파일 목록의 형식은 표준 .gitignore 파일과 같습니다.

느낌표(!)로 시작하는 패턴은 부정입니다. 이렇게 하면 이전 패턴과 일치하는 경로에 승인이 필요하지 않습니다 .
패턴은 순서대로 일치하므로 부정 패턴은 이전 규칙과 일치하는 파일을 "일치하지 않음"으로 설정할 수 있습니다.

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

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

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

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

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

규칙 집합에서 상태 검사를 구성하는 이슈를 해결하려면 문제 해결 규칙을(를) 참조하세요.

필수 상태 검사는 ‘느슨함' 또는 ‘엄격함' 두 가지 방식으로 적용할 수 있습니다. 선택한 필수 상태 검사의 유형은 분기를 병합하기 전에 기본 분기의 최신 상태로 업데이트해야 하는지 여부를 결정합니다.

필수 상태 검사 유형	설정	병합 요구 사항	고려 사항

          **엄격** | 
          **브랜치를 병합 전에 최신 상태로 유지해야 함** 확인란이 선택되어 있습니다. | 주제 분기를 병합하기 전에 **반드시** 기본 분기의 최신 상태로 업데이트해야 합니다. | 이는 필수 상태 검사의 기본 동작입니다. 다른 협력자가 타겟 브랜치를 업데이트한 이후, 헤드 브랜치를 최신 상태로 유지하기 위해 더 많은 빌드가 필요할 수 있습니다.|

| 느슨함 | 병합 전 분기 업데이트 필요 확인란을 선택하지 않습니다. | 분기를 병합하기 전에 기본 분기의 최신 상태로 업데이트할 필요가 없습니다. | 다른 협력자가 끌어오기 요청을 병합한 후 헤드 분기를 최신 상태로 만들 필요가 없으므로 필요한 빌드 수가 줄어듭니다. 기본 분기와 호환되지 않는 변경 내용이 있는 경우 분기를 병합한 후 상태 검사가 실패할 수 있습니다. | | 비활성화 | 병합 전 상태 확인 통과 필요 확인란을 선택하지 않습니다. | 브랜치에 병합 제한이 없습니다. | 필수 상태 검사를 사용하도록 설정하지 않은 경우 협력자는 기본 분기의 최신 상태인지 관계없이 언제든지 분기를 병합할 수 있습니다. 이렇게 하면 호환되지 않는 변경이 발생할 가능성이 증가합니다.

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

강제 푸시 차단

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

다른 사람이 분기 또는 태그에 강제로 푸시하는 경우, 다른 협력자가 작업을 기반으로 한 커밋은 분기 또는 태그의 기록에서 제거될 수 있습니다. 병합 충돌 또는 손상된 끌어오기 요청으로 이어질 수 있습니다. 강제 푸시를 통해 브랜치를 삭제하거나, 풀 리퀘스트에서 승인받지 못한 커밋을 가리키도록 브랜치를 재설정할 수도 있습니다.

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

code scanning 결과 필요

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

필수 도구는 규칙 집합에 정의된 심각도 수준에 따라 code scanning 경고를 식별합니다.
필수 도구의 분석은 아직 진행 중입니다.
리포지토리에 필요한 도구가 구성되지 않았습니다.

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

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

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

이 기사에서

생성 제한

업데이트 제한

삭제 제한

선형 기록 필요

배포가 성공적으로 완료되어야 병합 가능합니다.

서명된 커밋 필요

병합 전 끌어오기 요청 필요

추가 설정

필수 검토자

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

강제 푸시 차단

code scanning 결과 필요

파일 경로 제한

파일 경로 길이 제한

파일 확장명 제한

파일 크기 제한