呼和浩特机场旅客吞吐量再创新高

Introduction

For customers on GitHub Team or GitHub Enterprise plans you can create rulesets in your organization to control how users can interact with repositories in your organization. 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. You can also prevent people from renaming repositories.

You can also create push rulesets to block pushes to a private or internal repository and the repository's entire fork network. Push rulesets allow you to block pushes based on file extensions, file path lengths, file and folder paths, and file sizes.

Forks do not inherit branch or tag rulesets from their upstream repositories. However, forks owned by your organization are subject to the rulesets you create, like any other repository.

Forks do inherit push rulesets from their root repository. Push 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.

For 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.

Importing prebuilt rulesets

To import one of the prebuilt rulesets by GitHub, see github/ruleset-recipes.

You can import an existing ruleset using a JSON file. This can be useful if you want to apply the same ruleset to multiple repositories or organizations. For more information, see Managing rulesets for repositories in your organization.

Using fnmatch syntax

You can use fnmatch syntax to define patterns to target when you create a ruleset.

You can use the * wildcard to match any string of characters. Because GitHub uses the File::FNM_PATHNAME flag for the File.fnmatch syntax, the * wildcard does not match directory separators (/). For example, qa/* will match all branches beginning with qa/ and containing a single slash, but will not match qa/foo/bar. You can include any number of slashes after qa with qa/**/*, which would match, for example, qa/foo/bar/foobar/hello-world. You can also extend the qa string with qa**/**/* to make the rule more inclusive.

For more information about syntax options, see the fnmatch documentation.

Using ruleset enforcement statuses

While creating or editing your ruleset, you can use enforcement statuses to configure how your ruleset will be enforced.

You can select any of the following enforcement statuses for your ruleset.

• Active: your ruleset will be enforced upon creation.
• Disabled: your ruleset will not be enforced.

Creating a branch or tag ruleset

1. In the upper-right corner of GitHub, click your profile picture, then click Your organizations.

2. Next to the organization, click Settings.

3. In the left sidebar, in the "Code, planning, and automation" section, click Repository, then click Rulesets.

   

4. Click New ruleset.

5. To create a ruleset targeting branches, click New branch ruleset. Alternatively, to create a ruleset targeting tags, click New tag ruleset.

6. Under "Ruleset name," type a name for the ruleset.

7. Optionally, to change the default enforcement status, click Disabled and select an enforcement status. For more information about enforcement statuses, see About rulesets.

Choosing which repositories to target in your organization

With your ruleset, you can choose to target all repositories in your organization, repositories in your organization that match a certain naming convention, repositories in your organization that have custom properties, or a list of manually selected repositories in your organization.

For more information about custom properties, see Managing custom properties for repositories in your organization.

If a repository is targeted by a ruleset created at the organization level, only owners of the organization can edit the ruleset. However, people with admin access to the repository, or with a custom role including the "edit repository rules" permission, can create additional rulesets at the repository level. The rules in these rulesets will be aggregated with the rules defined at the organization level. The result is that creating a new ruleset can make the rules targeting a branch or tag more restrictive, but never less restrictive. For more information on creating rulesets, see About rulesets.

Targeting repositories by properties in your organization

You can target repositories in your organization by custom properties. See Managing custom properties for repositories in your organization.

1. To target a dynamic list of repositories in your organization by properties, in the "Target repositories" section, next to "Repository targeting criteria" select Repositories matching a filter.
2. To add a target, in the filter section, enter a query for example, visibility:private props.team:infra -language:java or Select by filter.
3. In the modal dialog that appears, select custom or system properties from the dropdown menu, then select a value for each property.
4. Click Apply.

Targeting all repositories in your organization

To target all repositories in your organization, in the "Target repositories" section, next to "Repository targeting criteria", select All repositories.

Targeting select repositories in your organization

1. To target a static, manually selected list of repositories in your organization, in the "Target repositories" section, next to "Repository targeting criteria", select Only selected repositories.
2. To select repositories to target, in the "Targeting criteria" section, select Select repositories, then search for the name of each repository you would like to target. Select each repository from the search results.

Targeting repositories by naming convention in your organization

1. To target a dynamic list of repositories in your organization by naming convention, in the "Target repositories" section, next to "Repository targeting criteria", select Repositories matching a name.

2. To begin defining a targeting pattern, in the "Targeting criteria" section, select Add a target , then click Include by pattern or Exclude by pattern.

3. In the modal dialog that appears, enter a repository naming pattern using fnmatch syntax, then click Add Inclusion pattern or Add Exclusion pattern. For more information on fnmatch syntax, see Using fnmatch syntax.

   Note

   You can add multiple targeting criteria to the same ruleset. For example, you could include any repositories matching the pattern *cat*, then specifically exclude a repository matching the pattern not-a-cat.

4. Optionally, on the ruleset configuration page, select Prevent renaming of target repositories.

Choosing which branches or tags to target

To target branches or tags, in the "Target branches" or "Target tags" section, select Add a target, then select how you want to include or exclude branches or tags. You can use fnmatch syntax to include or exclude branches or tags based on a pattern. For more information, see Using fnmatch syntax.

You can add multiple targeting criteria to the same ruleset. For example, you could include the default branch, include any branches matching the pattern *feature*, and then specifically exclude a branch matching the pattern not-a-feature.

Selecting branch or tag protections

In the "Branch protections" or "Tag protections" section, select the rules you want to include in the ruleset. When you select a rule, you may be able to enter additional settings for the rule. For more information on the rules, see Available rules for rulesets.

Finalizing your branch or tag ruleset and next steps

To finish creating your ruleset, click Create. If the enforcement status of the ruleset is set to "Active", the ruleset takes effect immediately.

Creating a push ruleset

You can create a push ruleset for private or internal repositories in your organization.

1. In the upper-right corner of GitHub, click your profile picture, then click Your organizations.

2. Next to the organization, click Settings.

3. In the left sidebar, in the "Code, planning, and automation" section, click Repository, then click Rulesets.

   

4. Click New ruleset.

5. To create a ruleset targeting branches, click New push ruleset.

6. Under "Ruleset name," type a name for the ruleset.

7. Optionally, to change the default enforcement status, click Disabled and select an enforcement status. For more information about enforcement statuses, see About rulesets.

Granting bypass permissions for your push ruleset

You can grant certain roles, teams, or apps bypass permissions for your ruleset. The following are eligible for bypass access:

• Repository admins, organization owners, and enterprise owners
• The maintain or write role, or custom repository roles based on the write role
• Teams, excluding secret teams. See About teams.
• GitHub Apps
• Dependabot. For more information about Dependabot, see Dependabot quickstart guide.

1. To grant bypass permissions for the ruleset, in the "Bypass list" section, click Add bypass.
2. In the "Add bypass" modal dialog that appears, search for the role, team, or app you would like to grant bypass permissions, then select the role, team, or app from the "Suggestions" section and click Add Selected.

Choosing which repositories to target in your organization

With your ruleset, you can choose to target all repositories in your organization, repositories in your organization that match a certain naming convention, repositories in your organization that have custom properties, or a list of manually selected repositories in your organization.

For more information about custom properties, see Managing custom properties for repositories in your organization.

If a repository is targeted by a ruleset created at the organization level, only owners of the organization can edit the ruleset. However, people with admin access to the repository, or with a custom role including the "edit repository rules" permission, can create additional rulesets at the repository level. The rules in these rulesets will be aggregated with the rules defined at the organization level. The result is that creating a new ruleset can make the rules targeting a branch or tag more restrictive, but never less restrictive. For more information on creating rulesets, see About rulesets.

Targeting repositories by properties in your organization

You can target repositories in your organization by custom properties. See Managing custom properties for repositories in your organization.

1. To target a dynamic list of repositories in your organization by properties, in the "Target repositories" section, next to "Repository targeting criteria" select Repositories matching a filter.
2. To add a target, in the filter section, enter a query for example, visibility:private props.team:infra -language:java or Select by filter.
3. In the modal dialog that appears, select custom or system properties from the dropdown menu, then select a value for each property.
4. Click Apply.

Targeting all repositories in your organization

To target all repositories in your organization, in the "Target repositories" section, next to "Repository targeting criteria", select All repositories.

Targeting select repositories in your organization

1. To target a static, manually selected list of repositories in your organization, in the "Target repositories" section, next to "Repository targeting criteria", select Only selected repositories.
2. To select repositories to target, in the "Targeting criteria" section, select Select repositories, then search for the name of each repository you would like to target. Select each repository from the search results.

Targeting repositories by naming convention in your organization

1. To target a dynamic list of repositories in your organization by naming convention, in the "Target repositories" section, next to "Repository targeting criteria", select Repositories matching a name.

2. To begin defining a targeting pattern, in the "Targeting criteria" section, select Add a target , then click Include by pattern or Exclude by pattern.

3. In the modal dialog that appears, enter a repository naming pattern using fnmatch syntax, then click Add Inclusion pattern or Add Exclusion pattern. For more information on fnmatch syntax, see Using fnmatch syntax.

   Note

   You can add multiple targeting criteria to the same ruleset. For example, you could include any repositories matching the pattern *cat*, then specifically exclude a repository matching the pattern not-a-cat.

4. Optionally, on the ruleset configuration page, select Prevent renaming of target repositories.

Selecting push protections

You can block pushes to this repository and this repository's entire fork network based on file extensions, file path lengths, file and folder paths, and file sizes.

Any push protections you configure will block pushes in this repository and throughout this repository's entire fork network.

1. Under "Push protections," click the restrictions you want to apply. Then fill in the details for the restrictions you select.

   For file path restrictions, you can use partial or full paths. 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.

Finalizing your push ruleset and next steps

To finish creating your ruleset, click Create. If the enforcement status of the ruleset is set to "Active", the ruleset takes effect immediately.