규칙 세트에 대한 정보

규칙 세트에 대한 정보

규칙 집합은 GitHub Team 및 GitHub Enterprise 플랜을 사용하는 고객을 위해 조직 내의 리포지토리 또는 다른 여러 리포지토리에 적용되는 명명된 규칙 목록입니다. 리포지토리당 최대 75개의 규칙 집합과 75개의 조직 전체 규칙 집합을 가질 수 있습니다.

규칙 세트를 만들 때 특정 사용자가 규칙 세트의 규칙을 무시하도록 허용할 수 있습니다. 리포지토리 관리자와 같은 특정 역할이 부여된 사용자이거나 특정 팀 또는 GitHub Apps일 수 있습니다. 바이패스 권한 부여에 대한 자세한 내용은 리포지토리에 대한 규칙 세트 만들기을(를) 참조하세요.

GitHub Enterprise 플랜에 있는 조직의 경우 조직 수준에서 규칙 집합을 설정하여 조직의 여러 리포지토리를 대상으로 지정할 수 있습니다. 자세한 내용은 조직의 리포지토리에 대한 규칙 집합 관리의 GitHub Enterprise Cloud 문서에서 확인하세요.

규칙 집합을 사용하여 리포지토리의 분기 또는 태그를 대상으로 지정하거나 리포지토리와 리포지토리의 전체 포크 네트워크에 대한 푸시를 차단할 수 있습니다.

브랜치 및 태그 규칙 집합

규칙 세트를 만들어 사용자가 리포지토리에서 선택한 분기 및 태그와 상호 작용하는 방법을 제어할 수 있습니다. 특정 분기에 커밋을 푸시할 수 있는 사용자, 태그를 삭제하거나 이름을 바꿀 수 있는 사용자와 같은 항목을 제어할 수 있습니다. 예를 들어 리포지토리 관리자를 제외한 모든 사용자에 대해 서명된 커밋이 필요하고 강제 푸시를 차단하는 리포지토리의 feature 분기에 대한 규칙 세트를 설정할 수 있습니다.

생성하는 각 규칙 세트에 대해 리포지토리에서 규칙 세트를 적용할 분기 또는 태그 지정할 수 있습니다. fnmatch 구문을 사용하여 특정 분기 및 태그를 대상으로 하는 패턴을 정의할 수 있습니다. 예를 들어 releases/**/* 패턴을 사용하여 이름이 releases/ 문자열로 시작하는 리포지토리의 모든 분기를 대상으로 지정할 수 있습니다. fnmatch 구문에 대한 자세한 내용은 리포지토리에 대한 규칙 세트 만들기을(를) 참조하세요.

푸시 규칙 세트

푸시 규칙 집합을 사용하면 파일 확장명, 파일 경로 길이, 파일 및 폴더 경로, 파일 크기에 따라 프라이빗 또는 내부 리포지토리와 해당 리포지토리의 전체 포크 네트워크에 대한 푸시를 차단할 수 있습니다.

푸시 규칙은 리포지토리에 대한 모든 푸시에 적용되므로 분기 대상 지정이 필요하지 않습니다.

푸시 규칙 집합을 사용하면 다음을 수행할 수 있습니다.

• 파일 경로 제한: 지정된 파일 경로의 변경 내용이 포함된 커밋이 푸시되지 않도록 합니다.

  이 테스트에 fnmatch 구문을 사용할 수 있습니다. 예를 들어 test/demo/**/*를 대상으로 하는 제한은 test/demo/ 디렉터리의 파일이나 폴더에 대한 푸시를 방지합니다. test/docs/pushrules.md를 대상으로 하는 제한 사항은 test/docs/ 디렉터리의 pushrules.md 파일에 대한 푸시를 방지합니다. 자세한 내용은 리포지토리에 대한 규칙 세트 만들기을(를) 참조하세요.

• 파일 경로 길이 제한: 지정된 문자 제한을 초과하는 파일 경로가 포함된 커밋이 푸시되지 않도록 합니다.

• 파일 확장명 제한: 지정된 파일 확장명의 파일이 포함된 커밋이 푸시되지 않도록 합니다.

• 파일 크기 제한: 지정된 파일 크기 제한을 초과하는 커밋이 푸시되지 않도록 합니다.

포크된 리포지토리에 대한 푸시 규칙 집합 정보

푸시 규칙은 리포지토리의 전체 포크 네트워크에 적용되어 리포지토리에 대한 모든 진입점이 보호되도록 합니다. 예를 들어 푸시 규칙 집합을 사용하도록 설정된 리포지토리를 포크하는 경우 포크된 리포지토리에도 동일한 푸시 규칙 집합이 적용됩니다.

포크된 리포지토리의 경우 푸시 규칙에 대한 바이패스 권한이 있는 사람은 루트 리포지토리에서 바이패스 권한이 있는 사용자뿐입니다.

규칙 세트 및 보호 대상 분기

규칙 세트는 리포지토리의 모든 분기 보호 규칙과 함께 작동합니다. 규칙 세트에서 정의할 수 있는 규칙 대부분은 보호 규칙과 비슷하며 기존 보호 규칙을 재정의하지 않고 규칙 세트를 사용할 수 있습니다.

규칙 세트는 분기 보호 규칙과 비교하여 다음과 같은 이점이 있습니다.

• 보호 규칙과 달리 여러 규칙 세트를 동시에 적용할 수 있어 다른 사용자가 해당 분기와 상호 작용할 때 리포지토리의 분기를 대상으로 하는 모든 규칙이 평가될 것이라고 확신할 수 있습니다. 규칙 계층화 정보를 참조하세요.
• 규칙 세트에 상태가 포함되어 규칙 세트를 삭제하지 않고도 리포지토리에서 활성 상태인 규칙 세트를 쉽게 관리할 수 있습니다.
• 리포지토리에 대한 읽기 권한이 있는 사용자는 해당 리포지토리의 활성 규칙 세트를 볼 수 있습니다. 따라서 개발자가 규칙에 도달한 이유를 이해할 수 있거나 감사자가 리포지토리에 대한 관리자 액세스 권한 없이 리포지토리의 보안 제약 조건을 검사할 수 있습니다.
• 리포지토리를 입력하는 커밋의 메타데이터(예: 커밋 메시지, 작성자의 이메일 주소)를 제어하는 추가 규칙을 만들 수 있습니다. 자세한 내용은 규칙 세트에 사용 가능한 규칙의 GitHub Enterprise Cloud 문서에서 확인하세요.

규칙 집합 적용 상태 사용

규칙 세트를 만들거나 편집하는 동안 적용 상태를 사용하여 규칙 세트를을 적용하는 방법을 구성할 수 있습니다.

규칙 세트에 대해 다음 적용 상태 중에서 선택할 수 있습니다.

•      **<svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-play" aria-label="play" role="img"><path d="M8 0a8 8 0 1 1 0 16A8 8 0 0 1 8 0ZM1.5 8a6.5 6.5 0 1 0 13 0 6.5 6.5 0 0 0-13 0Zm4.879-2.773 4.264 2.559a.25.25 0 0 1 0 .428l-4.264 2.559A.25.25 0 0 1 6 10.559V5.442a.25.25 0 0 1 .379-.215Z"></path></svg> 활성:** 규칙 세트가 생성 시에 적용됩니다.
  

•      **<svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-skip" aria-label="skip" role="img"><path d="M8 0a8 8 0 1 1 0 16A8 8 0 0 1 8 0ZM1.5 8a6.5 6.5 0 1 0 13 0 6.5 6.5 0 0 0-13 0Zm9.78-2.22-5.5 5.5a.749.749 0 0 1-1.275-.326.749.749 0 0 1 .215-.734l5.5-5.5a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042Z"></path></svg> 사용 안 함:** 규칙 세트가 적용되지 않습니다.
  

규칙 계층화에 대한 정보

규칙 세트에는 우선 순위가 없습니다. 대신 여러 규칙 세트가 리포지토리에서 동일한 분기 또는 태그를 대상으로 하는 경우 각 규칙 세트의 규칙이 집계됩니다. 동일한 규칙이 집계된 규칙 세트에서 서로 다른 방식으로 정의되는 경우 가장 제한적인 규칙 버전이 적용됩니다. 규칙 세트는 서로 계층화할 뿐만 아니라 동일한 분기 또는 태그를 대상으로 하는 보호 규칙과도 계층화합니다.

예를 들어 my-feature 리포지토리의 octo-org/octo-repo 분기에 대해 다음과 같은 상황을 고려합니다.

• 리포지토리 관리자가 my-feature 분기를 대상으로 하는 규칙 세트를 설정했습니다. 이 규칙 세트는 서명된 커밋과 끌어오기 요청에 대한 세 개의 검토가 있어야 병합할 수 있습니다.

•         `my-feature` 분기의 기존 분기 보호 규칙은 병합하기 전에 선형 커밋 기록과 끌어오기 요청에 대한 두 개의 검토가 필요합니다.
  

각 원본의 규칙이 집계되고 모든 규칙이 적용됩니다. 동일한 규칙의 버전이 여러 개 있는 경우 가장 제한적인 규칙 버전이 적용됩니다. 따라서 my-feature 분기는 서명된 커밋과 선형 커밋 기록, 해당 분기를 대상으로 하는 끌어오기 요청은 병합하기 전에 세 개의 검토가 필요합니다.