Skip to main content

이 버전의 GitHub Enterprise Server는 다음 날짜에 중단됩니다. 2026-04-09. 중요한 보안 문제에 대해서도 패치 릴리스가 이루어지지 않습니다. 더 뛰어난 성능, 향상된 보안, 새로운 기능을 위해 최신 버전의 GitHub Enterprise Server로 업그레이드합니다. 업그레이드에 대한 도움말은 GitHub Enterprise 지원에 문의하세요.

규칙 세트에 대한 정보

규칙 세트는 사용자가 리포지토리에서 분기 및 태그와 상호 작용하는 방법을 제어하는 데 도움이 됩니다.

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

리포지토리에 대한 읽기 권한이 있는 사용자는 해당 리포지토리의 규칙 세트를 볼 수 있습니다. 리포지토리에 대한 관리자 액세스 권한이 있거나 "리포지토리 규칙 편집" 권한이 있는 사용자 지정 역할이 있는 사용자는 리포지토리에 대한 규칙 집합을 생성, 편집, 삭제하고 규칙 집합 인사이트를 볼 수 있습니다. 자세한 내용은 사용자 지정 리포지토리 역할 정보을(를) 참조하세요.

규칙 세트는 조직의 GitHub Free 및 GitHub Free가 있는 퍼블릭 리포지토리와 GitHub Pro, GitHub Team, GitHub Enterprise Cloud의 퍼블릭 리포지토리 및 프라이빗 리포지토리에서 사용할 수 있습니다.

규칙 세트에 대한 정보

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

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

브랜치 및 태그 규칙 집합

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

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

규칙 집합, 보호 대상 브랜치 및 보호 대상 태그 정보

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

또한 기존 태그 보호 규칙을 리포지토리 규칙 집합으로 가져올 수 있습니다. 이렇게 하면 리포지토리에서 현재 배치된 것과 동일한 태그 보호가 구현됩니다. 태그 보호 규칙 구성을(를) 참조하세요.

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

  • 보호 규칙과 달리 여러 규칙 세트를 동시에 적용할 수 있어 다른 사용자가 해당 분기나 태그와 상호 작용할 때 리포지토리의 분기나 태그를 대상으로 하는 모든 규칙이 평가될 것이라고 확신할 수 있습니다. 규칙 계층화 정보를 참조하세요.
  • 규칙 세트에 상태가 포함되어 규칙 세트를 삭제하지 않고도 리포지토리에서 활성 상태인 규칙 세트를 쉽게 관리할 수 있습니다.
  • 리포지토리에 대한 읽기 권한이 있는 사용자는 해당 리포지토리의 활성 규칙 세트를 볼 수 있습니다. 따라서 개발자가 규칙에 도달한 이유를 이해할 수 있거나 감사자가 리포지토리에 대한 관리자 액세스 권한 없이 리포지토리의 보안 제약 조건을 검사할 수 있습니다.
  • 리포지토리를 입력하는 커밋의 메타데이터(예: 커밋 메시지, 작성자의 이메일 주소)를 제어하는 추가 규칙을 만들 수 있습니다. 자세한 내용은 규칙 세트에 사용 가능한 규칙의 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-meter" aria-label="meter" role="img"><path d="M8 1.5a6.5 6.5 0 1 0 6.016 4.035.75.75 0 0 1 1.388-.57 8 8 0 1 1-4.37-4.37.75.75 0 1 1-.569 1.389A6.473 6.473 0 0 0 8 1.5Zm6.28.22a.75.75 0 0 1 0 1.06l-4.063 4.064a2.5 2.5 0 1 1-1.06-1.06L13.22 1.72a.75.75 0 0 1 1.06 0ZM7 8a1 1 0 1 0 2 0 1 1 0 0 0-2 0Z"></path></svg> 평가:** 규칙 세트가 적용되지 않지만 "Rule Insights" 페이지에서 규칙을 위반하거나 위반하지 않는 작업을 모니터링할 수 있습니다.
    
  •      **<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` 분기의 기존 분기 보호 규칙은 병합하기 전에 선형 커밋 기록과 끌어오기 요청에 대한 두 개의 검토가 필요합니다.
    
  •         `octo-org` 조직의 관리자도 `my-feature` 리포지토리의 `octo-repo`분기를 대상으로 하는 규칙 세트를 설정했습니다. 규칙 세트는 강제 푸시를 차단하며, 병합하기 전에 끌어오기 요청에 대해 한 번의 검토가 필요합니다.
    

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