About rulesets

Learn how you can use rulesets to control how people interact with pushes, branches, and tags in repositories.

この記事の内容

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

ルールセットの作成または編集中に、適用ステータスを使用してルールセットの適用方法を構成できます。

ルールセットには、次の適用ステータスのいずれかを選択できます。

  • アクティブ: ルールセットは作成時に適用されます。
  • 評価: ルールセットは適用されませんが、[Rule Insights] ページでルールに違反するアクションと違反しないアクションを監視できます。
  • 無効: ルールセットは、適用または評価されません。

「評価」モードを使用することは、ルールセットを適用せずにテストするための優れたオプションです。 「ルールの分析情報」ページを使用して、そのコントリビューションがルールに違反したかどうかを確認できます。 詳しくは、「リポジトリのルールセットの管理」をご覧ください。

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.