{"meta":{"title":"About rulesets","intro":"Rulesets help you to control how people can interact with branches and tags in a repository.","product":"Repositories","breadcrumbs":[{"href":"/en/repositories","title":"Repositories"},{"href":"/en/repositories/configuring-branches-and-merges-in-your-repository","title":"Branches and merges"},{"href":"/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets","title":"Manage rulesets"},{"href":"/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets","title":"About rulesets"}],"documentType":"article"},"body":"# About rulesets\n\nRulesets help you to control how people can interact with branches and tags in a repository.\n\n## About rulesets\n\nA ruleset is a named list of rules that applies to a repository or to multiple repositories in an organization for customers on GitHub Team and GitHub Enterprise plans. You can have up to 75 rulesets per repository, and 75 organization-wide rulesets.\n\nWhen 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 [Creating rulesets for a repository](/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#granting-bypass-permissions-for-your-ruleset).\n\nFor organizations on the GitHub Enterprise plan, you can set up rulesets at the organization level to target multiple repositories in your organization. See [Managing rulesets for repositories in your organization](/en/enterprise-cloud@latest/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization) in the GitHub Enterprise Cloud documentation.\n\nYou 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.\n\n### Branch and tag rulesets\n\nYou 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, 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.\n\nFor each ruleset you create, you specify which branches or tags in your repository the ruleset applies to. You can use `fnmatch` syntax to define a pattern to target specific branches and tags. 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 [Creating rulesets for a repository](/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#using-fnmatch-syntax).\n\n### Push rulesets\n\nWith push rulesets, you can block pushes to a private or internal repository and that repository's entire fork network based on file extensions, file path lengths, file and folder paths, and file sizes.\n\nPush rules do not require any branch targeting because they apply to every push to the repository.\n\nPush rulesets allow you to:\n\n* **Restrict file paths:** Prevent commits that include changes in specified file paths from being pushed.\n\n You can use `fnmatch` syntax for this. For example, a restriction targeting `test/demo/**/*` prevents any pushes to files or folders in the `test/demo/` directory. A restriction targeting `test/docs/pushrules.md` prevents pushes specifically to the `pushrules.md` file in the `test/docs/` directory. For more information, see [Creating rulesets for a repository](/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#using-fnmatch-syntax).\n* **Restrict file path length:** Prevent commits that include file paths that exceed a specified character limit from being pushed.\n* **Restrict file extensions:** Prevent commits that include files with specified file extensions from being pushed.\n* **Restrict file size:** Prevent commits that exceed a specified file size limit from being pushed.\n\n### About push rulesets for forked repositories\n\nPush rules apply to the entire fork network for a repository, ensuring every entry point to the repository is protected. For example, if you fork a repository that has push rulesets enabled, the same push rulesets will also apply to your forked repository.\n\nFor a forked repository, the only people who have bypass permissions for a push rule are the people who have bypass permissions in the root repository.\n\n## About rulesets and protected branches\n\nRulesets 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.\n\nRulesets have the following advantages over branch protection rules.\n\n* 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](#about-rule-layering).\n* Rulesets have statuses, so you can easily manage which rulesets are active in a repository without needing to delete rulesets.\n* 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.\n* 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 [Available rules for rulesets](/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#metadata-restrictions) in the GitHub Enterprise Cloud documentation.\n\n## Using ruleset enforcement statuses\n\nWhile creating or editing your ruleset, you can use enforcement statuses to configure how your ruleset will be enforced.\n\nYou can select any of the following enforcement statuses for your ruleset.\n\n* ** Active:** your ruleset will be enforced upon creation.\n* ** Disabled:** your ruleset will not be enforced.\n\n## About rule layering\n\nA 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.\n\nFor example, consider the following situation for the `my-feature` branch of the `octo-org/octo-repo` repository.\n\n* 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.\n* 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.\n\nThe 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, and pull requests targeting the branch will require three reviews before they can be merged."}