About rulesets

A ruleset is a named list of rules that applies to a repository, or to multiple repositories in an organization. You can have up to 75 rulesets per repository, and 75 organization-wide rulesets.

When you create a ruleset, you can allow certain users to bypass the rules in the ruleset. This can be users with a certain role, such as repository administrator, or it can be specific teams or GitHub Apps. For more information about granting bypass permissions, see 리포지토리에 대한 규칙 세트 만들기.

For organizations on the GitHub Enterprise plan, you can set up rulesets at the enterprise or organization level to target multiple repositories in your organization. See 조직의 리포지토리에 대한 규칙 집합 관리.

You can use rulesets to target branches or tags in a repository or to block pushes to a repository and the repository's entire fork network.

Note

푸시 규칙에 대한 위임된 바이패스는 현재 공개 미리 보기 버전이며 변경될 수 있습니다.

돌려주기 규칙 세트를 위해 위임된 바이패스를 사용하면 돌려주기 보호를 바이패스할 수 있는 사용자와 허용해야 하는 차단된 돌려주기를 제어할 수 있습니다.

위임된 바이패스를 사용하면 리포지토리에 대한 기여자는 제한된 콘텐츠가 포함된 커밋을 돌려줄 때 "권한 바이패스"를 요청해야 합니다. 요청은 돌려주기 규칙을 바이패스하는 요청을 승인하거나 거부하는 지정된 검토자 그룹으로 전송됩니다.

돌려주기 규칙 바이패스 요청이 승인되는 경우 기여자는 제한된 콘텐츠가 포함된 커밋을 돌려줄 수 있습니다. 요청이 거부되는 경우 기여자는 다시 돌려주기 전에 제한된 콘텐츠가 포함된 하나 이상의 커밋에서 콘텐츠를 제거해야 합니다.

위임된 바이패스를 구성하려면 조직 소유자 또는 리포지토리 관리자가 먼저 "바이패스 목록"을 만듭니다. 바이패스 목록에는 돌려주기 보호 바이패스 요청을 감독하는 팀 또는 리포지토리 관리자와 같은 특정 역할과 팀이 포함됩니다. 자세한 내용은 조직의 리포지토리에 대한 규칙 집합 관리 및 규칙 세트 정보을(를) 참조하세요.

Branch and tag rulesets

You can create rulesets to control how people can interact with selected branches and tags in a repository. You can control things like who can push commits to a certain branch and how the commits must be formatted, or who can delete or rename a tag. For example, you could set up a ruleset for your repository's feature branch that requires signed commits and blocks force pushes for all users except repository administrators.

For each ruleset you create, you specify which branches or tags in your repository, or which repositories in your organization, the ruleset applies to. You can use fnmatch syntax to define a pattern to target specific branches, tags, and repositories. For example, you could use the pattern releases/**/* to target all branches in your repository whose name starts with the string releases/. For more information on fnmatch syntax, see 리포지토리에 대한 규칙 세트 만들기.

Push rulesets

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

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

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

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

이 테스트에 fnmatch 구문을 사용할 수 있습니다. 예를 들어 test/demo/**/*를 대상으로 하는 제한은 test/demo/ 디렉터리의 파일이나 폴더에 대한 푸시를 방지합니다. test/docs/pushrules.md를 대상으로 하는 제한 사항은 test/docs/ 디렉터리의 pushrules.md 파일에 대한 푸시를 방지합니다. 자세한 내용은 리포지토리에 대한 규칙 세트 만들기을(를) 참조하세요.
파일 경로 길이 제한: 지정된 문자 제한을 초과하는 파일 경로가 포함된 커밋이 푸시되지 않도록 합니다.
파일 확장명 제한: 지정된 파일 확장명의 파일이 포함된 커밋이 푸시되지 않도록 합니다.
파일 크기 제한: 지정된 파일 크기 제한을 초과하는 커밋이 푸시되지 않도록 합니다.

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

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

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

About rulesets and protected branches

Rulesets work alongside any branch protection rules in a repository. Many of the rules you can define in rulesets are similar to protection rules, and you can start using rulesets without overriding any of your existing protection rules.

Rulesets have the following advantages over branch protection rules.

Unlike protection rules, multiple rulesets can apply at the same time, so you can be confident that every rule targeting a branch in your repository will be evaluated when someone interacts with that branch. See About rule layering.
Rulesets have statuses, so you can easily manage which rulesets are active in a repository without needing to delete rulesets.
Anyone with read access to a repository can view the active rulesets for the repository. This means a developer can understand why they have hit a rule, or an auditor can check the security constraints for the repository, without requiring admin access to the repository.
You can create additional rules to control the metadata of commits entering a repository, such as the commit message and the author's email address. See 규칙 세트에 사용 가능한 규칙."

Using ruleset enforcement statuses

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

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

활성: 규칙 세트가 생성 시에 적용됩니다.
평가: 규칙 세트가 적용되지 않지만 “규칙 인사이트” 페이지에서 규칙을 위반하거나 위반하지 않는 작업을 모니터링할 수 있습니다.
사용 안 함: 규칙 세트가 적용되거나 평가되지 않습니다.

"평가" 모드를 사용하는 것은 규칙 세트를 적용하지 않고 테스트하는 데 유용한 옵션입니다. "규칙 인사이트" 페이지를 사용하여 기여가 규칙을 위반했는지 확인할 수 있습니다. 자세한 내용은 리포지토리에 대한 규칙 세트 관리을(를) 참조하세요.

About rule layering

A ruleset does not have a priority. Instead, if multiple rulesets target the same branch or tag in a repository, the rules in each of these rulesets are aggregated. If the same rule is defined in different ways across the aggregated rulesets, the most restrictive version of the rule applies. As well as layering with each other, rulesets also layer with protection rules targeting the same branch or tag.

For example, consider the following situation for the my-feature branch of the octo-org/octo-repo repository.

An administrator of the repository has set up a ruleset targeting the my-feature branch. This ruleset requires signed commits, and three reviews on pull requests before they can be merged.
An existing branch protection rule for the my-feature branch requires a linear commit history, and two reviews on pull requests before they can be merged.
An administrator of the octo-org organization has also set up a ruleset targeting the my-feature branch of the octo-repo repository. The ruleset blocks force pushes, and requires one review on pull requests before they can be merged.

The rules from each source are aggregated, and all rules apply. Where multiple different versions of the same rule exist, the result is that the most restrictive version of the rule applies. Therefore, the my-feature branch requires signed commits and a linear commit history, force pushes are blocked, and pull requests targeting the branch will require three reviews before they can be merged.

Next steps

Next, learn how to communicate important information with members of your enterprise using READMEs. See Create a README for your enterprise.

About rulesets

이 문서의 내용