[2023-04-17]: Repository Rules [Public Beta] (#35983)

Co-authored-by: Steve Guntrip <stevecat@github.com>
Co-authored-by: Greg Beaty <gregbty@github.com>

content/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-personal-account-settings/permission-levels-for-a-personal-account-repository.md

@@ -37,7 +37,7 @@ The repository owner has full control of the repository. In addition to the acti
 | Change the visibility of the repository | "[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility)" |{% ifversion fpt or ghec %}
 | Limit interactions with the repository | "[AUTOTITLE](/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository)" |{% endif %}
 | Rename a branch, including the default branch | "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch)" |
-| Merge a pull request on a protected branch, even if there are no approving reviews | "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)" |
+| Merge a pull request on a protected branch, even if there are no approving reviews | "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)" |
 | Delete the repository | "[AUTOTITLE](/repositories/creating-and-managing-repositories/deleting-a-repository)" |
 | Manage the repository's topics | "[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/classifying-your-repository-with-topics)" |{% ifversion fpt or ghec %}
 | Manage security and analysis settings for the repository | "[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-security-and-analysis-settings-for-your-repository)" |{% endif %}{% ifversion fpt or ghec %}

content/actions/deployment/targeting-different-environments/using-environments-for-deployment.md

@@ -58,7 +58,7 @@ Prevent admins from being able to bypass the configured environment protection r
 Use deployment branches to restrict which branches can deploy to the environment. Below are the options for deployment branches for an environment:
 
 * **All branches**: All branches in the repository can deploy to the environment.
-* **Protected branches**: Only branches with branch protection rules enabled can deploy to the environment. If no branch protection rules are defined for any branch in the repository, then all branches can deploy. For more information about branch protection rules, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)."
+* **Protected branches**: Only branches with branch protection rules enabled can deploy to the environment. If no branch protection rules are defined for any branch in the repository, then all branches can deploy. For more information about branch protection rules, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."
 * **Selected branches**: Only branches that match your specified name patterns can deploy to the environment.
 
   For example, if you specify `releases/*` as a deployment branch rule, only branches whose name begins with `releases/` can deploy to the environment. (Wildcard characters will not match `/`. To match branches that begin with `release/` and contain an additional single slash, use `release/*/*`.) If you add `main` as a deployment branch rule, a branch named `main` can also deploy to the environment. For more information about syntax options for deployment branches, see the [Ruby File.fnmatch documentation](https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch).

content/actions/using-workflows/events-that-trigger-workflows.md

@@ -41,7 +41,7 @@ Some events have multiple activity types. For these events, you can specify whic
 
 {% data reusables.actions.branch-requirement %}
 
-Runs your workflow when branch protection rules in the workflow repository are changed. For more information about branch protection rules, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)." For information about the branch protection rule APIs, see "[AUTOTITLE](/graphql/reference/objects#branchprotectionrule)" in the GraphQL API documentation or "[AUTOTITLE](/rest/branches)" in the REST API documentation.
+Runs your workflow when branch protection rules in the workflow repository are changed. For more information about branch protection rules, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)." For information about the branch protection rule APIs, see "[AUTOTITLE](/graphql/reference/objects#branchprotectionrule)" in the GraphQL API documentation or "[AUTOTITLE](/rest/branches)" in the REST API documentation.
 
 For example, you can run a workflow when a branch protection rule has been `created` or `deleted`:
 

content/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise.md

@@ -1251,8 +1251,8 @@ Before you'll see `git` category actions, you must enable Git events in the audi
 
 | Action | Description
 |--------|-------------
-| `required_status_check.create` | A status check was marked as required for a protected branch. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging)."
-| `required_status_check.destroy` | A status check was no longer marked as required for a protected branch. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging)."
+| `required_status_check.create` | A status check was marked as required for a protected branch. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging)."
+| `required_status_check.destroy` | A status check was no longer marked as required for a protected branch. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging)."
 
 {%- ifversion ghec or ghes %}
 ## `restrict_notification_delivery` category actions

content/admin/policies/enforcing-policy-with-pre-receive-hooks/creating-a-pre-receive-hook-script.md

@@ -93,7 +93,7 @@ The `$GITHUB_VIA` variable is available in the pre-receive hook environment when
 {%- ifversion ghes %}
 | `merge ` | Merge of a pull request using auto-merge | "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request)" |
 {%- endif %}
-| <pre>merge base into head</pre> | Update of the topic branch from the base branch when the base branch requires strict status checks (via **Update branch** in a pull request, for example) | "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging)" |
+| <pre>merge base into head</pre> | Update of the topic branch from the base branch when the base branch requires strict status checks (via **Update branch** in a pull request, for example) | "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging)" |
 | <pre>pull request branch delete button</pre> | Deletion of a topic branch from a pull request in the web interface | "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/deleting-and-restoring-branches-in-a-pull-request#deleting-a-branch-used-for-a-pull-request)" |
 | <pre>pull request branch undo button</pre> | Restoration of a topic branch from a pull request in the web interface | "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/deleting-and-restoring-branches-in-a-pull-request#restoring-a-deleted-branch)" |
 | <pre>pull request merge api</pre> | Merge of a pull request via the API | "[AUTOTITLE](/rest/pulls#merge-a-pull-request)" in the REST API documentation |

content/apps/creating-github-apps/guides/creating-ci-tests-with-the-checks-api.md

@@ -28,7 +28,7 @@ A CI server hosts code that runs CI tests such as code linters (which check styl
 
 The [Checks API](/rest/checks) allows you to set up CI tests that are automatically run against each code commit in a repository. The Checks API reports detailed information about each check on GitHub in the pull request's **Checks** tab. With the Checks API, you can create annotations with additional details for specific lines of code. Annotations are visible in the **Checks** tab. When you create an annotation for a file that is part of the pull request, the annotations are also shown in the **Files changed** tab.
 
-A _check suite_ is a group of _check runs_ (individual CI tests). Both the suite and the runs contain _statuses_ that are visible in a pull request on GitHub. You can use statuses to determine when a code commit introduces errors. Using these statuses with [protected branches](/rest/repos#branches) can prevent people from merging pull requests prematurely. See "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging)" for more details.
+A _check suite_ is a group of _check runs_ (individual CI tests). Both the suite and the runs contain _statuses_ that are visible in a pull request on GitHub. You can use statuses to determine when a code commit introduces errors. Using these statuses with [protected branches](/rest/repos#branches) can prevent people from merging pull requests prematurely. See "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging)" for more details.
 
 The Checks API sends the [`check_suite` webhook event](/webhooks-and-events/webhooks/webhook-events-and-payloads#check_suite) to all GitHub Apps installed on a repository each time new code is pushed to the repository. To receive all Checks API event actions, the app must have the `checks:write` permission. GitHub automatically creates `check_suite` events for new code commits in a repository using the default flow, although [Update repository preferences for check suites](/rest/checks#update-repository-preferences-for-check-suites) if you'd like. Here's how the default flow works:
 

content/authentication/managing-commit-signature-verification/about-commit-signature-verification.md

@@ -58,7 +58,7 @@ For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-me
 {% endif %}
 
 
-Repository administrators can enforce required commit signing on a branch to block all commits that are not signed and verified. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-signed-commits)."
+Repository administrators can enforce required commit signing on a branch to block all commits that are not signed and verified. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-signed-commits)."
 
 {% data reusables.identity-and-permissions.verification-status-check %}
 

content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/triaging-code-scanning-alerts-in-pull-requests.md

@@ -38,7 +38,7 @@ If you have write permission for the repository, you can see any existing {% dat
 
 In repositories where {% data variables.product.prodname_code_scanning %} is configured to scan each time code is pushed, {% data variables.product.prodname_code_scanning %} will also map the results to any open pull requests and add the alerts as annotations in the same places as other pull request checks. For more information, see "[AUTOTITLE](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/customizing-code-scanning#scanning-on-push)."
 
-If your pull request targets a protected branch that uses {% data variables.product.prodname_code_scanning %}, and the repository owner has configured required status checks, then the "{% data variables.product.prodname_code_scanning_caps %} results" check must pass before you can merge the pull request. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging)."
+If your pull request targets a protected branch that uses {% data variables.product.prodname_code_scanning %}, and the repository owner has configured required status checks, then the "{% data variables.product.prodname_code_scanning_caps %} results" check must pass before you can merge the pull request. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging)."
 
 ## About {% data variables.product.prodname_code_scanning %} as a pull request check
 
@@ -106,7 +106,7 @@ In the detailed view for an alert, some {% data variables.product.prodname_code_
 
 You can comment on any {% data variables.product.prodname_code_scanning %} alert {% ifversion code-scanning-alerts-in-pr-diff %}that appears in a pull request. Alerts appear as annotations in the **Conversation** tab of a pull request, as part of a  pull request review, and also are shown in the **Files changed** tab{% else %}introduced by the changes in a pull request. Alerts appear as annotations in the **Conversation** tab of a pull request, as part of a  pull request review, and also are shown in the **Files changed** tab. You can only comment on alerts introduced by the changes in a pull request. Existing {% data variables.product.prodname_code_scanning %} alerts, on files that are outside the changes introduced in the pull request, will appear in the **Files changed** tab but cannot be commented on{% endif %}.
 
-You can choose to require all conversations in a pull request, including those on {% data variables.product.prodname_code_scanning %} alerts, to be resolved before a pull request can be merged. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-conversation-resolution-before-merging)."
+You can choose to require all conversations in a pull request, including those on {% data variables.product.prodname_code_scanning %} alerts, to be resolved before a pull request can be merged. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-conversation-resolution-before-merging)."
 {% endif %}
 ## Fixing an alert on your pull request
 

content/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions.md

@@ -229,11 +229,11 @@ jobs:
 
 ### Enable auto-merge on a pull request
 
-If you want to allow maintainers to mark certain pull requests for auto-merge, you can use {% data variables.product.prodname_dotcom %}'s auto-merge functionality. This enables the pull request to be merged when any tests and approvals required by the branch protection rules are successfully met. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request)" and "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+If you want to allow maintainers to mark certain pull requests for auto-merge, you can use {% data variables.product.prodname_dotcom %}'s auto-merge functionality. This enables the pull request to be merged when any tests and approvals required by the branch protection rules are successfully met. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request)" and "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
 
 {% note %}
 
-**Note:** If you use status checks to test pull requests, you should enable **Require status checks to pass before merging** for the target branch for {% data variables.product.prodname_dependabot %} pull requests. This branch protection rule ensures that pull requests are not merged unless all the required status checks pass. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+**Note:** If you use status checks to test pull requests, you should enable **Require status checks to pass before merging** for the target branch for {% data variables.product.prodname_dependabot %} pull requests. This branch protection rule ensures that pull requests are not merged unless all the required status checks pass. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
 
 {% endnote %}
 

content/code-security/security-advisories/repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability.md

@@ -80,7 +80,7 @@ Anyone with admin permissions to a security advisory can merge changes in a secu
 
 {% data reusables.repositories.merge-all-pulls-together %}
 
-Before you can merge changes in a security advisory, every open pull request in the temporary private fork must be mergeable. To keep information about vulnerabilities secure, status checks do not run on pull requests in temporary private forks. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)."
+Before you can merge changes in a security advisory, every open pull request in the temporary private fork must be mergeable. To keep information about vulnerabilities secure, status checks do not run on pull requests in temporary private forks. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."
 
 Additionally, there can be no merge conflicts, and {% data variables.product.prodname_dotcom %} won't enforce any of the protection rules that you may have set up for the branch you're trying to merge the changes in to.
 

content/code-security/supply-chain-security/end-to-end-supply-chain/securing-code.md

@@ -113,7 +113,7 @@ Besides your code, you probably need to use secrets in other places. For example
 
 ### Create a pull request review process
 
-You can improve the quality and security of your code by ensuring that all pull requests are reviewed and tested before they are merged. {% data variables.product.prodname_dotcom %} has many features you can use to control the review and merge process. To get started, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)."
+You can improve the quality and security of your code by ensuring that all pull requests are reviewed and tested before they are merged. {% data variables.product.prodname_dotcom %} has many features you can use to control the review and merge process. To get started, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."
 
 ### Scan your code for vulnerable patterns
 

content/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review.md

@@ -54,7 +54,7 @@ You can use the {% data variables.dependency-review.action_name %} in your repos
 
 ![Screenshot of a workflow run that uses the Dependency review action.](/assets/images/help/graphs/dependency-review-action.png)
 
-By default, the {% data variables.dependency-review.action_name %} check will fail if it discovers any vulnerable packages. A failed check blocks a pull request from being merged when the repository owner requires the dependency review check to pass. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging)."
+By default, the {% data variables.dependency-review.action_name %} check will fail if it discovers any vulnerable packages. A failed check blocks a pull request from being merged when the repository owner requires the dependency review check to pass. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging)."
 
 {% ifversion fpt or ghec or ghes %}
 The action uses the Dependency Review REST API to get the diff of dependency changes between the base commit and head commit. You can use the Dependency Review API to get the diff of dependency changes, including vulnerability data, between any two commits on a repository. For more information, see "[AUTOTITLE](/rest/dependency-graph#dependency-review)."

content/desktop/contributing-and-collaborating-using-github-desktop/making-changes-in-a-branch/committing-and-reviewing-changes-to-your-project.md

@@ -112,7 +112,7 @@ Once you're satisfied with the changes you've chosen to include in your commit,
     - To move your changes, click **switch branches**.
     - To commit your changes to the protected branch, click **Commit to BRANCH**.
 
-  For more information about protected branches, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)."
+  For more information about protected branches, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."
 {% data reusables.desktop.push-origin %}
 
 6. If you have a pull request based off the branch you are working on, {% data variables.product.prodname_desktop %} will display the status of the checks that have run for the pull request next to the "Current Branch" section of the repository bar. For more information about checks, see "[AUTOTITLE](/desktop/contributing-and-collaborating-using-github-desktop/working-with-your-remote-repository-on-github-or-github-enterprise/viewing-and-re-running-checks-in-github-desktop)."

content/get-started/quickstart/github-flow.md

@@ -88,7 +88,7 @@ Once your pull request is approved, merge your pull request. This will automatic
 
 {% data variables.product.prodname_dotcom %} will tell you if your pull request has conflicts that must be resolved before merging. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts)."
 
-Branch protection settings may block merging if your pull request does not meet certain requirements. For example, you need a certain number of approving reviews or an approving review from a specific team. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)."
+Branch protection settings may block merging if your pull request does not meet certain requirements. For example, you need a certain number of approving reviews or an approving review from a specific team. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."
 
 ### Delete your branch
 

content/issues/tracking-your-work-with-issues/filtering-and-searching-issues-and-pull-requests.md

@@ -105,7 +105,7 @@ You can use filters to list pull requests by review status and to find pull requ
 
 You can filter a repository's list of pull requests to find:
 - Pull requests that haven't been [reviewed](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews) yet
-- Pull requests that [require a review](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging) before they can be merged
+- Pull requests that [require a review](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-pull-request-reviews-before-merging) before they can be merged
 - Pull requests that a reviewer has approved
 - Pull requests in which a reviewer has asked for changes
 - Pull requests that you have reviewed
@@ -186,7 +186,7 @@ For issues, you can also use search to:
 For pull requests, you can also use search to:
 - Filter [draft](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests) pull requests: `is:draft`
 - Filter pull requests that haven't been [reviewed](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews) yet: `state:open type:pr review:none`
-- Filter pull requests that [require a review](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging) before they can be merged: `state:open type:pr review:required`
+- Filter pull requests that [require a review](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-pull-request-reviews-before-merging) before they can be merged: `state:open type:pr review:required`
 - Filter pull requests that a reviewer has approved: `state:open type:pr review:approved`
 - Filter pull requests in which a reviewer has asked for changes: `state:open type:pr review:changes_requested`
 - Filter pull requests by [reviewer](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews): `state:open type:pr reviewed-by:octocat`

content/migrations/using-github-enterprise-importer/understanding-github-enterprise-importer/migration-support-for-github-enterprise-importer.md

@@ -113,7 +113,7 @@ When you migrate a repository directly, teams and team access to repositories ar
 
 ### Branch protections
 
-Branch protections apply a specified set of rules to a specific branch name or branch name pattern. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)."
+Branch protections apply a specified set of rules to a specific branch name or branch name pattern. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."
 
 Branch protections will always be migrated, but certain rules will not be migrated. The following branch protection rules are not migrated.
 

content/organizations/managing-organization-settings/index.md

@@ -44,6 +44,7 @@ children:
   - /disabling-project-boards-in-your-organization
   - /disabling-insights-for-projects-in-your-organization
   - /allowing-project-visibility-changes-in-your-organization
+  - /managing-rulesets-for-repositories-in-your-organization
 shortTitle: Manage organization settings
 ---
 {% ifversion fpt or ghec %}

content/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization.md

@@ -0,0 +1,84 @@
+---
+title: Managing rulesets for repositories in your organization
+intro: 'You can create a ruleset to target multiple repositories in your organization.'
+versions:
+  feature: repo-rules-enterprise
+permissions: 'Organization owners can manage rulesets at the organization level.'
+topics:
+  - Organizations
+shortTitle: Manage rulesets
+---
+
+{% data reusables.repositories.rulesets-public-beta %}
+
+## About managing rulesets for an organization
+
+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.
+
+When you create a ruleset for an organization, you use `fnmatch` syntax to define which repositories in your organization, and which branches or tags in those repositories, are targeted by the ruleset. For more information, see "[Using fnmatch syntax](#using-fnmatch-syntax)." This provides a quicker way for managing rulesets than creating a separate ruleset for each repository you want to target.
+
+{% data reusables.repositories.ruleset-bypass %}
+
+If a repository is targeted by a ruleset created at organization level, only owners of the organization can edit this 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 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, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
+
+{% data reusables.repositories.rulesets-sudo-mode %}
+
+Forks do not inherit rulesets from their upstream repositories. However, forks owned by your organization are subject to the rulesets you create, like any other repository.
+
+{% data reusables.repositories.rulesets-anyone-can-view %}
+
+## Creating a ruleset
+
+{% data reusables.profile.access_org %}
+{% data reusables.profile.org_settings %}
+{% data reusables.organizations.access-ruleset-settings %}
+{% data reusables.repositories.create-ruleset-step %}
+{% data reusables.repositories.rulesets-general-step %}
+{% data reusables.repositories.rulesets-bypass-step %}
+1. In the "Target repositories" section, select **Add a target** to add repositories. You can include all repositories in your organization, or you can use `fnmatch` syntax to include or exclude repository names based on a pattern. For more information, see "[Using `fnmatch` syntax](#using-fnmatch-syntax)."
+
+   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`.
+
+   Optionally, to prevent users from renaming any of the targeted repositories, select **Prevent renaming of target repositories**.
+{% data reusables.repositories.rulesets-target-branches %}
+{% data reusables.repositories.rulesets-protections-step %}
+{% data reusables.repositories.rulesets-metadata-step %}
+{% data reusables.repositories.rulesets-create-step %}
+
+## Editing a ruleset
+
+{% data reusables.repositories.about-editing-rulesets %}
+
+{% data reusables.profile.access_org %}
+{% data reusables.profile.org_settings %}
+{% data reusables.organizations.access-ruleset-settings %}
+{% data reusables.repositories.edit-ruleset-steps %}
+
+## Deleting a ruleset
+
+{% data reusables.repositories.deleting-ruleset-tip %}
+
+{% data reusables.profile.access_org %}
+{% data reusables.profile.org_settings %}
+{% data reusables.organizations.access-ruleset-settings %}
+{% data reusables.repositories.delete-ruleset-steps %}
+
+## Viewing insights for rulesets
+
+You can view insights for rulesets to see how rulesets are affecting the repositories in your organization. {% data reusables.repositories.about-ruleset-insights %}
+
+{% data reusables.profile.access_org %}
+{% data reusables.profile.org_settings %}
+1. In the left sidebar, in the "Code, planning, and automation" section, click **{% octicon "repo" aria-hidden="true" %} Repository**, then click **Repository rule insights**.
+
+   ![Screenshot of an organization's settings page. In the sidebar, a link labeled "Repository rule insights" is outlined in orange.](/assets/images/help/organizations/repository-rule-insights.png)
+1. On the "Rule Insights" page, use the dropdown menus at the top of the page to filter the actions by ruleset, repository, actor, and time period.
+{% data reusables.repositories.rulesets-view-rule-runs %}
+
+## Using `fnmatch` syntax
+
+{% data reusables.repositories.rulesets-fnmatch %}
+
+## Using regular expressions for commit metadata
+
+{% data reusables.repositories.rulesets-commit-regex %}

content/organizations/managing-user-access-to-your-organizations-repositories/repository-roles-for-an-organization.md

@@ -110,8 +110,9 @@ Some of the features listed below are limited to organizations using {% data var
 | Enable project boards | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} |
 | Configure [pull request merges](/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges) | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} |
 | Configure [a publishing source for {% data variables.product.prodname_pages %}](/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site) | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} |
-| [Manage branch protection rules](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule) | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} |
-| [Push to protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches) | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} |
+| Manage [branch protection rules](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule){% ifversion repo-rules %} and [repository rulesets](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets){% endif %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} |{% ifversion repo-rules %}
+| View [rulesets for a repository](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets) | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} |
+{% endif %}| [Push to protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} |
 | Merge pull requests on protected branches, even if there are no approving reviews | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} |{% ifversion fpt or ghes > 3.4 or ghae > 3.4 or ghec %}
 | Create tags that match a [tag protection rule](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-tag-protection-rules) | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} |
 | Delete tags that match a [tag protection rule](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-tag-protection-rules) | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} |{% endif %}

content/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github.md

@@ -24,7 +24,7 @@ If a site administrator disables the merge conflict editor for pull requests bet
 
 {% warning %}
 
-**Warning:** When you resolve a merge conflict on {% data variables.product.product_name %},  the entire [base branch](/get-started/quickstart/github-glossary#base-branch) of your pull request is merged into the [head branch](/get-started/quickstart/github-glossary#head-branch). Make sure you really want to commit to this branch. If the head branch is the default branch of your repository, you'll be given the option of creating a new branch to serve as the head branch for your pull request. If the head branch is protected you won't be able to merge your conflict resolution into it, so you'll be prompted to create a new head branch. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)."
+**Warning:** When you resolve a merge conflict on {% data variables.product.product_name %},  the entire [base branch](/get-started/quickstart/github-glossary#base-branch) of your pull request is merged into the [head branch](/get-started/quickstart/github-glossary#head-branch). Make sure you really want to commit to this branch. If the head branch is the default branch of your repository, you'll be given the option of creating a new branch to serve as the head branch for your pull request. If the head branch is protected you won't be able to merge your conflict resolution into it, so you'll be prompted to create a new head branch. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."
 
 {% endwarning %}
 

content/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges.md

@@ -82,7 +82,7 @@ A pull request can be merged automatically if its head branch is directly or ind
 
 If pull request **E** --> `main` is merged first, pull request **D** --> `main` will be marked as merged *automatically* because all of the commits from `feature` are now reachable from `main`. Merging `feature_2` into `main` and pushing `main` to the server from the command line will mark *both* pull requests as merged.
 
-Pull requests in this situation will be marked as `merged` even if [branch protection rules](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#about-branch-protection-rules) have not been satisfied.
+Pull requests in this situation will be marked as `merged` even if [branch protection rules](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#about-branch-protection-rules) have not been satisfied.
 
 ## Further reading
 

content/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request.md

@@ -16,7 +16,7 @@ topics:
 ---
 ## About pull request merges
 
-In a pull request, you propose that changes you've made on a head branch should be merged into a base branch. By default, any pull request can be merged at any time, unless the head branch is in conflict with the base branch. However, there may be restrictions on when you can merge a pull request into a specific branch. For example, you may only be able to merge a pull request into the default branch if required status checks are passing. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)."
+In a pull request, you propose that changes you've made on a head branch should be merged into a base branch. By default, any pull request can be merged at any time, unless the head branch is in conflict with the base branch. However, there may be restrictions on when you can merge a pull request into a specific branch. For example, you may only be able to merge a pull request into the default branch if required status checks are passing. Repository administrators can add constraints like this to branches using branch protection rules{% ifversion repo-rules %} or repository rulesets{% endif %}. For more information, see {% ifversion repo-rules %}"[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)" and "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."{% else %}"[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."{% endif %}
 
 {% data reusables.pull_requests.you-can-auto-merge %}
 

content/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches.md

@@ -64,7 +64,7 @@ Repository administrators {% ifversion edit-repository-rules %}or custom roles w
 
 {% endnote %}
 
-To see if your pull request can be merged, look in the merge box at the bottom of the pull request's **Conversation** tab. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)."
+To see if your pull request can be merged, look in the merge box at the bottom of the pull request's **Conversation** tab. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."
 
 When a branch is protected:
 
@@ -72,7 +72,7 @@ When a branch is protected:
 - If required status checks are enabled on the branch, you won't be able to merge changes into the branch until all of the required CI tests pass. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks)."
 - If required pull request reviews are enabled on the branch, you won't be able to merge changes into the branch until all requirements in the pull request review policy have been met. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request)."
 - If required review from a code owner is enabled on a branch, and a pull request modifies code that has an owner, a code owner must approve the pull request before it can be merged. For more information, see "[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)."
-- If required commit signing is enabled on a branch, you won't be able to push any commits to the branch that are not signed and verified. For more information, see "[AUTOTITLE](/authentication/managing-commit-signature-verification/about-commit-signature-verification)" and "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-signed-commits)."
+- If required commit signing is enabled on a branch, you won't be able to push any commits to the branch that are not signed and verified. For more information, see "[AUTOTITLE](/authentication/managing-commit-signature-verification/about-commit-signature-verification)" and "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-signed-commits)."
 - If you use {% data variables.product.prodname_dotcom %}'s conflict editor to fix conflicts for a pull request that you created from a protected branch, {% data variables.product.prodname_dotcom %}  helps you to create an alternative branch for the pull request, so that your resolution of the conflicts can be merged. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github)."
 
 ## Further reading

content/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork.md

@@ -19,7 +19,7 @@ You can only make commits on pull request branches that:
 - are opened in a repository that you have push access to and that were created from a fork of that repository
 - are on a user-owned fork
 - have permission granted from the pull request creator
-- don't have [branch restrictions](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#restrict-who-can-push-to-matching-branches) that will prevent you from committing
+- don't have [branch restrictions](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#restrict-who-can-push-to-matching-branches) that will prevent you from committing
 
 Only the user who created the pull request can give you permission to push commits to the user-owned fork. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork)."
 

content/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/keeping-your-pull-request-in-sync-with-the-base-branch.md

@@ -22,7 +22,7 @@ You can update a pull request's head branch from the command line or the pull re
 * The pull request branch is not up to date with the base branch.
 * The base branch requires branches to be up to date before merging{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %} or the setting to always suggest updating branches is enabled{% endif %}.
 
-For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches){% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}" and "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-suggestions-to-update-pull-request-branches){% endif %}."
+For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches){% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}" and "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-suggestions-to-update-pull-request-branches){% endif %}."
 
 If there are changes to the base branch that cause merge conflicts in your pull request branch, you will not be able to update the branch until all conflicts are resolved. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/about-merge-conflicts)."
 

content/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews.md

@@ -48,7 +48,7 @@ You can view all of the reviews a pull request has received in the Conversation
 
 ## Required reviews
 
-{% data reusables.pull_requests.required-reviews-for-prs-summary %} For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging)."
+{% data reusables.pull_requests.required-reviews-for-prs-summary %} For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-pull-request-reviews-before-merging)."
 
 {% tip %}
 

content/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/approving-a-pull-request-with-required-reviews.md

@@ -15,7 +15,7 @@ topics:
   - Pull requests
 shortTitle: Required reviews
 ---
-For more information about required reviews, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging)."
+For more information about required reviews, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-pull-request-reviews-before-merging)."
 
 You can comment on a pull request, approve the changes, or request improvements before approving. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)."
 

content/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/dismissing-a-pull-request-review.md

@@ -36,4 +36,4 @@ This changes the status of the review to a review comment. When you dismiss a re
 
 - "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews)"
 - "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)"
-- "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging)"
+- "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-pull-request-reviews-before-merging)"

content/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request.md

@@ -115,5 +115,5 @@ After you've finished reviewing all the files you want in the pull request, subm
 
 ## Further reading
 
-- "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging)"
+- "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-pull-request-reviews-before-merging)"
 - "[AUTOTITLE](/issues/tracking-your-work-with-issues/filtering-and-searching-issues-and-pull-requests)"

content/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github.md

@@ -26,7 +26,7 @@ shortTitle: About merge methods
 
 {% data reusables.pull_requests.default_merge_option %}
 
-The default merge method creates a merge commit. You can prevent anyone from pushing merge commits to a protected branch by enforcing a linear commit history. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-linear-history)."
+The default merge method creates a merge commit. You can prevent anyone from pushing merge commits to a protected branch by enforcing a linear commit history. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-linear-history)."
 
 ## Squashing your merge commits
 

content/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue.md

@@ -56,7 +56,7 @@ With other CI providers, you may need to update your CI configuration to run whe
 
 ## Managing a merge queue
 
-Repository administrators can require a merge queue by enabling the branch protection setting "Require merge queue" in the protection rules for the base branch. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule#creating-a-branch-protection-rule)."
+Repository administrators can require a merge queue by enabling the branch protection setting "Require merge queue" in the protection rules for the base branch. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule#creating-a-branch-protection-rule)."
 
 
 Once you have enabled "require merge queue," you can also access the following settings:
@@ -78,4 +78,4 @@ Once you have enabled "require merge queue," you can also access the following s
 ## Further reading
 
 * "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request-with-a-merge-queue)"
-* "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)"
+* "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)"

content/repositories/configuring-branches-and-merges-in-your-repository/index.md

@@ -11,7 +11,8 @@ topics:
 children:
   - /managing-branches-in-your-repository
   - /configuring-pull-request-merges
-  - /defining-the-mergeability-of-pull-requests
+  - /managing-protected-branches
+  - /managing-rulesets
 shortTitle: Branches and merges
 ---
 

content/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch.md

@@ -1,7 +1,7 @@
 ---
 title: Renaming a branch
 intro: You can change the name of a branch in a repository.
-permissions: 'People with write permissions to a repository can rename a branch in the repository unless it is the [default branch](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches#about-the-default-branch){% ifversion fpt or ghec or ghes %} or a [protected branch](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches){% endif %}. People with admin permissions can rename the default branch{% ifversion fpt or ghec or ghes %} and protected branches{% endif %}.'
+permissions: 'People with write permissions to a repository can rename a branch in the repository unless it is the [default branch](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches#about-the-default-branch){% ifversion fpt or ghec or ghes %} or a [protected branch](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches){% endif %}. People with admin permissions can rename the default branch{% ifversion fpt or ghec or ghes %} and protected branches{% endif %}.'
 versions:
   fpt: '*'
   ghes: '*'

content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches.md

@@ -17,6 +17,7 @@ redirect_from:
   - /github/administering-a-repository/about-required-reviews-for-pull-requests
   - /github/administering-a-repository/about-protected-branches
   - /github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches
+  - /repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches
 versions:
   fpt: '*'
   ghes: '*'
@@ -36,10 +37,18 @@ By default, the restrictions of a branch protection rule don't apply to people w
 {% else %}
 By default, the restrictions of a branch protection rule don't apply to people with admin permissions to the repository. You can optionally choose to include administrators, too.{% endif %}
 
-{% data reusables.repositories.branch-rules-example %} For more information about branch name patterns, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+{% data reusables.repositories.branch-rules-example %} For more information about branch name patterns, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
 
 {% data reusables.pull_requests.you-can-auto-merge %}
 
+{% ifversion repo-rules %}
+{% tip %}
+
+**Tip:** Only a single branch protection rule can apply at a time, which means it can be difficult to know which rule will apply when multiple versions of a rule target the same branch. {% ifversion repo-rules-enterprise %}Additionally, you may want to create a single set of rules that applies to multiple repositories in an organization. {% endif %}For information about an alternative to branch protection rules, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
+
+{% endtip %}
+{% endif %}
+
 ## About branch protection settings
 
 For each branch protection rule, you can choose to enable or disable the following settings.
@@ -62,7 +71,7 @@ For each branch protection rule, you can choose to enable or disable the followi
 - [Allow force pushes](#allow-force-pushes)
 - [Allow deletions](#allow-deletions)
 
-For more information on how to set up branch protection, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+For more information on how to set up branch protection, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
 
 ### Require pull request reviews before merging
 
@@ -81,21 +90,23 @@ remote: error: GH006: Protected branch update failed for refs/heads/main.
 remote: error: Changes have been requested.
 ```
 
-Optionally, you can choose to dismiss stale pull request approvals when commits are pushed. If anyone pushes a commit that modifies code to an approved pull request, the approval will be dismissed, and the pull request cannot be merged. This doesn't apply if the collaborator pushes commits that don't modify code, like merging the base branch into the pull request's branch. For information about the base branch, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)."
+Optionally, you can choose to dismiss stale pull request approvals when commits are pushed that affect the diff in the pull request. {% data variables.product.company_short %} records the state of the diff at the point when a pull request is approved. This state represents the set of changes that the reviewer approved. If the diff changes from this state (for example, because a contributor pushes new changes to the pull request branch or clicks **Update branch**, or because a related pull request is merged into the target branch), the approving review is dismissed as stale, and the pull request cannot be merged until someone approves the work again. For information about the base branch, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)."
 
 Optionally, you can restrict the ability to dismiss pull request reviews to specific people or teams. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/dismissing-a-pull-request-review)."
 
 Optionally, you can choose to require reviews from code owners. If you do, any pull request that affects code with a code owner must be approved by that code owner before the pull request can be merged into the protected branch.
 
 {% ifversion last-pusher-require-approval %}
-Optionally, you can require approvals from someone other than the last person to push to a branch before a pull request can be merged. This ensures more than one person sees pull requests in their final state before they are merged into a protected branch. If you enable this feature, the most recent user to push their changes will need an approval regardless of the required approvals branch protection. Users who have already reviewed a pull request can reapprove after the most recent push to meet this requirement.
+Optionally, you can require an approval from someone other than the last person to push to a branch before a pull request can be merged. This means at least one other authorized reviewer has approved any changes. For example, the "last reviewer" can check that the latest set of changes incorporates feedback from other reviews, and does not add new, unreviewed content.
+
+For complex pull requests that require many reviews, requiring an approval from someone other than the last person to push can be a compromise that avoids the need to dismiss all stale reviews: with this option, "stale" reviews are not dismissed, and the pull request remains approved as long as someone other than the person who made the most recent changes approves it. Users who have already reviewed a pull request can reapprove after the most recent push to meet this requirement. If you are concerned about pull requests being "hijacked" (where unapproved content is added to approved pull requests), it is safer to dismiss stale reviews.
 {% endif %}
 
 ### Require status checks before merging
 
 Required status checks ensure that all required CI tests are passing before collaborators can make changes to a protected branch. Required status checks can be checks or statuses. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks)."
 
-Before you can enable required status checks, you must configure the repository to use the commit status API. For more information, see "[AUTOTITLE](/rest/commits/statuses)" in the REST API documentation.
+You can use the commit status API to allow external services to mark commits with an appropriate status.. For more information, see "[AUTOTITLE](/rest/commits/statuses)" in the REST API documentation.
 
 After enabling required status checks, all required status checks must pass before collaborators can merge changes into the protected branch. After all required status checks pass, any commits must either be pushed to another branch and then merged or pushed directly to the protected branch.
 
@@ -105,11 +116,11 @@ You can set up required status checks to either be "loose" or "strict." The type
 
 | Type of required status check | Setting | Merge requirements | Considerations |
 | --- | --- | --- | --- |
-| **Strict** | The **Require branches to be up to date before merging** checkbox is checked. | The branch **must** be up to date with the base branch before merging. | This is the default behavior for required status checks. More builds may be required, as you'll need to bring the head branch up to date after other collaborators merge pull requests to the protected base branch.|
+| **Strict** | The **Require branches to be up to date before merging** checkbox is checked. | The branch **must** be up to date with the base branch before merging. | This is the default behavior for required status checks. More builds may be required, as you'll need to bring the head branch up to date after other collaborators update the target branch.|
 | **Loose** | The **Require branches to be up to date before merging** checkbox is **not** checked. | The branch **does not** have to be up to date with the base branch before merging. | You'll have fewer required builds, as you won't need to bring the head branch up to date after other collaborators merge pull requests. Status checks may fail after you merge your branch if there are incompatible changes with the base branch. |
 | **Disabled** | The **Require status checks to pass before merging** checkbox is **not** checked. | The branch has no merge restrictions. | If required status checks aren't enabled, collaborators can merge the branch at any time, regardless of whether it is up to date with the base branch. This increases the possibility of incompatible changes.
 
-For troubleshooting information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks)."
+For troubleshooting information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/troubleshooting-required-status-checks)."
 
 ### Require conversation resolution before merging
 
@@ -196,7 +207,7 @@ By default, {% data variables.product.product_name %} blocks force pushes on all
 1. Allow everyone with at least write permissions to the repository to force push to the branch, including those with admin permissions.
 1. Allow only specific people or teams to force push to the branch.
 
-If someone force pushes to a branch, the force push may overwrite commits that other collaborators based their work on. People may have merge conflicts or corrupted pull requests.
+If someone force pushes to a branch, the force push may mean commits that other collaborators based their work on are removed from the history of the branch. People may have merge conflicts or corrupted pull requests. Force pushing can also be used to delete branches or point a branch to commits that were not approved in a pull request.
 
 Enabling force pushes will not override any other branch protection rules. For example, if a branch requires a linear commit history, you cannot force push merge commits to that branch.
 

content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/index.md

@@ -1,11 +1,12 @@
 ---
-title: Defining the mergeability of pull requests
-intro: 'You can require pull requests to pass a set of checks before they can be merged. For example, you can block pull requests that don''t pass status checks or require that pull requests have a specific number of approving reviews before they can be merged.'
+title: Managing protected branches
+intro: 'You can set up rules to protect certain branches in your repository. For example, you can block pull requests that don''t pass status checks or require that pull requests have a specific number of approving reviews before they can be merged.'
 redirect_from:
   - /articles/defining-the-mergeability-of-a-pull-request
   - /articles/defining-the-mergeability-of-pull-requests
   - /enterprise/admin/developer-workflow/establishing-pull-request-merge-conditions
   - /github/administering-a-repository/defining-the-mergeability-of-pull-requests
+  - /repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests
 product: '{% data reusables.gated-features.protected-branches %}'
 versions:
   fpt: '*'
@@ -18,6 +19,6 @@ children:
   - /about-protected-branches
   - /managing-a-branch-protection-rule
   - /troubleshooting-required-status-checks
-shortTitle: Mergeability of PRs
+shortTitle: Manage protected branches
 ---
 

content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule.md

@@ -18,6 +18,7 @@ redirect_from:
   - /github/administering-a-repository/enabling-deletion-of-a-protected-branch
   - /github/administering-a-repository/managing-a-branch-protection-rule
   - /github/administering-a-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule
+  - /repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule
 versions:
   fpt: '*'
   ghes: '*'
@@ -32,7 +33,7 @@ shortTitle: Branch protection rule
 
 {% data reusables.repositories.branch-rules-example %}
 
-You can create a rule for all current and future branches in your repository with the wildcard syntax `*`. Because {% data variables.product.company_short %} 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. You can include multiple slashes with `qa/**/*`, and you can extend the `qa` string with `qa**/**/*` to make the rule more inclusive. For more information about syntax options for branch rules, see the [fnmatch documentation](https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch).
+You can create a rule for all current and future branches in your repository with the wildcard syntax `*`. {% data reusables.repositories.about-fnmatch %}
 
 If a repository has multiple protected branch rules that affect the same branches, the rules that include a specific branch name have the highest priority. If there is more than one protected branch rule that references the same specific branch name, then the branch rule created first will have higher priority.
 
@@ -40,7 +41,15 @@ Protected branch rules that mention a special character, such as `*`, `?`, or `]
 
 To create an exception to an existing branch rule, you can create a new branch protection rule that is higher priority, such as a branch rule for a specific branch name.
 
-For more information about each of the available branch protection settings, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)."
+For more information about each of the available branch protection settings, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."
+
+{% ifversion repo-rules %}
+{% tip %}
+
+**Tip:** Only a single branch protection rule can apply at a time, which means it can be difficult to know how which rule will apply when multiple versions of a rule target the same branch. {% ifversion repo-rules-enterprise %}Additionally, you may want to create a single set of rules that applies to multiple repositories in an organization. {% endif %}For information about an alternative to branch protection rules, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
+
+{% endtip %}
+{% endif %}
 
 ## Creating a branch protection rule
 
@@ -99,7 +108,7 @@ When you create a branch rule, the branch you specify doesn't have to exist yet
    - Select **Everyone** to allow everyone with at least write permissions to the repository to force push to the branch, including those with admin permissions.
    - Select **Specify who can force push** to allow only specific actors to force push to the branch. Then, search for and select those actors.
 
-    For more information about force pushes, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#allow-force-pushes)."
+    For more information about force pushes, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#allow-force-pushes)."
 1. Optionally, select **Allow deletions**.
 1. Click **Create**.
 

content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/troubleshooting-required-status-checks.md

@@ -12,11 +12,12 @@ topics:
 redirect_from:
   - /github/administering-a-repository/troubleshooting-required-status-checks
   - /github/administering-a-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks
+  - /repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks
 shortTitle: Required status checks
 ---
 If you have a check and a status with the same name, and you select that name as a required status check, both the check and the status are required. For more information, see "[AUTOTITLE](/rest/checks)."
 
-After you enable required status checks, your branch may need to be up-to-date with the base branch before merging. This ensures that your branch has been tested with the latest code from the base branch. If your branch is out of date, you'll need to merge the base branch into your branch. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging)."
+After you enable required status checks, your branch may need to be up-to-date with the base branch before merging. This ensures that your branch has been tested with the latest code from the base branch. If your branch is out of date, you'll need to merge the base branch into your branch. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging)."
 
 {% note %}
 

content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets.md

@@ -0,0 +1,49 @@
+---
+title: About rulesets
+intro: 'Rulesets help you to control how people can interact with branches and tags in a repository.'
+product: '{% data reusables.gated-features.repo-rules %}'
+versions:
+  feature: repo-rules
+permissions: '{% data reusables.repositories.repo-rules-permissions %}'
+topics:
+  - Repositories
+shortTitle: About rulesets
+---
+
+{% data reusables.repositories.rulesets-public-beta %}
+
+## About rulesets
+
+A ruleset is a named list of rules that applies to a repository{% ifversion repo-rules-enterprise %}, or to multiple repositories in an organization{% endif %}. 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{% ifversion repo-rules-enterprise %} and how the commits must be formatted{% endif %}, 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{% ifversion repo-rules-enterprise %}, or which repositories in your organization,{% endif %} the ruleset applies to. You can use `fnmatch` syntax to define a pattern to target specific {% ifversion repo-rules-enterprise %}branches, tags, and repositories{% else %}branches and tags{% endif %}. 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 "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository#using-fnmatch-syntax)."
+
+{% data reusables.repositories.ruleset-bypass %}
+
+## About rulesets, protected branches, and protected tags
+
+Rulesets work alongside any branch protection rules and tag 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 and tag protection rules.
+
+- Unlike protection rules, multiple rulesets can apply at the same time, so you can be confident that every rule targeting a branch or tag in your repository will be evaluated when someone interacts with that branch or tag. For more information, see "[About rule layering](#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.
+
+In addition, for organizations on a {% data variables.product.prodname_enterprise %} plan, you can do the following things with rulesets.
+
+- Quickly set up rulesets at the organization level to target multiple repositories in your organization. For more information, see "[AUTOTITLE](/enterprise-cloud@latest/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization){% ifversion ghec %}."{% else %}" in the {% data variables.product.prodname_ghe_cloud %} documentation.{% endif %}
+- Create additional rules to control the metadata of commits entering a repository, such as the commit message and the author's email address. For more information, see "[AUTOTITLE](/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#metadata-restrictions){% ifversion ghec %}."{% else %}" in the {% data variables.product.prodname_ghe_cloud %} documentation.{% endif %}
+- Use an "Evaluate" status to test a ruleset before making it active, and use an insights page to view which user actions are being affected by rules. For more information, see "[AUTOTITLE](/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository#viewing-insights-for-rulesets){% ifversion ghec %}."{% else %}" in the {% data variables.product.prodname_ghe_cloud %} documentation.{% endif %}
+
+## 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.{% ifversion repo-rules-enterprise %}
+- 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.{% endif %}
+
+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{% ifversion repo-rules-enterprise %}, force pushes are blocked{% endif %}, and pull requests targeting the branch will require three reviews before they can be merged.

content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets.md

@@ -0,0 +1,167 @@
+---
+title: Available rules for rulesets
+intro: 'Learn which rules you can add to a ruleset to protect specific branches and tags in a repository.'
+product: '{% data reusables.gated-features.repo-rules %}'
+versions:
+  feature: repo-rules
+permissions: '{% data reusables.repositories.repo-rules-permissions %}'
+topics:
+  - Repositories
+shortTitle: Available rules
+---
+
+{% data reusables.repositories.rulesets-public-beta %}
+
+You can create rulesets to control how users can interact with selected branches and tags in a repository. When you create a ruleset, you can choose to enable or disable the rules described in the following sections. 
+
+When you create a ruleset, you can allow certain users to bypass the rules in the ruleset. This can be users with certain permissions, specific teams, or {% data variables.product.prodname_github_apps %}. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
+
+For more information on creating and managing rulesets, see {% ifversion ghec %}"[AUTOTITLE](/enterprise-cloud@latest/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization)" and {% endif %}"[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository)."
+
+## Restrict creations
+
+If selected, only users with bypass permissions can create branches or tags whose name matches the pattern you specify.
+
+## Restrict updates
+
+If selected, only users with bypass permissions can push to branches or tags whose name matches the pattern you specify.
+
+## Restrict deletions
+
+If selected, only users with bypass permissions can delete branches or tags whose name matches the pattern you specify. This rule is selected by default.
+
+## Require linear history
+
+Enforcing a linear commit history prevents collaborators from pushing merge commits to the targeted branches or tags. This means that any pull requests merged into the branch or tag must use a squash merge or a rebase merge. A strictly linear commit history can help teams reverse changes more easily. For more information about merge methods, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges)."
+
+Before you can require a linear commit history, your repository must allow squash merging or rebase merging. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges)."
+
+## Require deployments to succeed before merging
+
+{% ifversion repo-rules-enterprise %}
+{% note %}
+
+**Note:** This rule is not available for rulesets created at the organization level.
+
+{% endnote %}
+{% endif %}
+
+You can require that changes are successfully deployed to specific environments before a branch can be merged. For example, you can use this rule to ensure that changes are successfully deployed to a staging environment before the changes merge to your default branch.
+
+## Require signed commits
+
+When you enable required commit signing on a branch, contributors {% ifversion fpt or ghec %}and bots{% endif %} can only push commits that have been signed and verified to the branch. For more information, see "[AUTOTITLE](/authentication/managing-commit-signature-verification/about-commit-signature-verification)."
+
+{% note %}
+
+{% ifversion fpt or ghec %}
+**Notes:**
+
+* If you have enabled vigilant mode in your account settings, which indicates that your commits will always be signed, any commits that {% data variables.product.prodname_dotcom %} identifies as "Partially verified" are permitted on branches that require signed commits. For more information about vigilant mode, see "[AUTOTITLE](/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits)."
+* If a collaborator pushes an unsigned commit to a branch that requires commit signatures, the collaborator will need to rebase the commit to include a verified signature, then force push the rewritten commit to the branch.
+
+{% else %}
+**Note:** If a collaborator pushes an unsigned commit to a branch that requires commit signatures, the collaborator will need to rebase the commit to include a verified signature, then force push the rewritten commit to the branch.
+{% endif %}
+
+{% endnote %}
+
+You can always push local commits to the branch if the commits are signed and verified. {% ifversion fpt or ghec %}You can also merge signed and verified commits into the branch using a pull request on {% data variables.product.product_name %}. However, you cannot squash and merge a pull request into the branch on {% data variables.product.product_name %} unless you are the author of the pull request.{% else %} However, you cannot merge pull requests into the branch on {% data variables.product.product_name %}.{% endif %} You can {% ifversion fpt or ghec %}squash and {% endif %}merge pull requests locally. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally)."
+
+{% ifversion fpt or ghec %} For more information about merge methods, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github)."{% endif %}
+
+## Require a pull request before merging
+
+You can require that all changes to the target branch be associated with a pull request. The pull request doesn't necessarily have to be approved, but it must be opened.
+
+### Additional settings
+
+{% data reusables.pull_requests.required-reviews-for-prs-summary %}
+
+If you enable required reviews, collaborators can only push changes to a branch via a pull request that is approved by the required number of reviewers with write permissions.
+
+If someone chooses the **Request changes** option in a review, then that person must approve the pull request before the pull request can be merged. If a reviewer who requests changes on a pull request isn't available, anyone with write permissions for the repository can dismiss the blocking review.
+
+{% data reusables.repositories.review-policy-overlapping-commits %}
+
+Optionally, you can choose to dismiss stale pull request approvals when commits are pushed that affect the diff in the pull request. {% data variables.product.company_short %} records the state of the diff at the point when a pull request is approved. This state represents the set of changes that the reviewer approved. If the diff changes from this state (for example, because a contributor pushes new changes to the pull request branch or clicks **Update branch**, or because a related pull request is merged into the target branch), the approving review is dismissed as stale, and the pull request cannot be merged until someone approves the work again. For information about the target branch branch, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)."
+
+Optionally, you can choose to require reviews from code owners. If you do, any pull request that modifies content with a code owner must be approved by that code owner before the pull request can be merged into the protected branch.
+
+{% ifversion last-pusher-require-approval %}
+Optionally, you can require an approval from someone other than the last person to push to a branch before a pull request can be merged. This means at least one other authorized reviewer has approved any changes. For example, the "last reviewer" can check that the latest set of changes incorporates feedback from other reviews, and does not add new, unreviewed content.
+
+For complex pull requests that require many reviews, requiring an approval from someone other than the last person to push can be a compromise that avoids the need to dismiss all stale reviews: with this option, "stale" reviews are not dismissed, and the pull request remains approved as long as someone other than the person who made the most recent changes approves it. Users who have already reviewed a pull request can reapprove after the most recent push to meet this requirement. If you are concerned about pull requests being "hijacked" (where unapproved content is added to approved pull requests), it is safer to dismiss stale reviews.
+{% endif %}
+
+Optionally, you can require all comments on the pull request to be resolved before it can be merged to a branch. This ensures that all comments are addressed or acknowledged before merge.
+
+## Require status checks to pass before merging
+
+Required status checks ensure that all required CI tests are passing before collaborators can make changes to a branch or tag targeted by your ruleset. Required status checks can be checks or statuses. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks)."
+
+You can use the commit status API to allow external services to mark commits with an appropriate status. For more information, see "[AUTOTITLE](/rest/commits/statuses)" in the REST API documentation.
+
+After enabling required status checks, all required status checks must pass before collaborators can merge changes into the branch or tag. After all required status checks pass, any commits must either be pushed to another branch and then merged or pushed directly to the branch or tag.
+
+Any person or integration with write permissions to a repository can set the state of any status check in the repository, but in some cases you may only want to accept a status check from a specific {% data variables.product.prodname_github_app %}. When you add a required status check, you can select an app as the expected source of status updates. The app must be installed in the repository with the `statuses:write` permission, must have recently submitted a check run, and must be associated with a pre-existing required status check in the ruleset. If the status is set by any other person or integration, merging won't be allowed. If you select "any source", you can still manually verify the author of each status, listed in the merge box.
+
+You can think of required status checks as being either "loose" or "strict." The type of required status check you choose determines whether your branch is required to be up to date with the base branch before merging.
+
+| Type of required status check | Setting | Merge requirements | Considerations |
+| --- | --- | --- | --- |
+| **Strict** | The **Require branches to be up to date before merging** checkbox is checked. | The topic branch **must** be up to date with the base branch before merging. | This is the default behavior for required status checks. More builds may be required, as you'll need to bring the head branch up to date after other collaborators update the target branch.|
+| **Loose** | The **Require branches to be up to date before merging** checkbox is **not** checked. | The branch **does not** have to be up to date with the base branch before merging. | You'll have fewer required builds, as you won't need to bring the head branch up to date after other collaborators merge pull requests. Status checks may fail after you merge your branch if there are incompatible changes with the base branch. |
+| **Disabled** | The **Require status checks to pass before merging** checkbox is **not** checked. | The branch has no merge restrictions. | If required status checks aren't enabled, collaborators can merge the branch at any time, regardless of whether it is up to date with the base branch. This increases the possibility of incompatible changes.
+
+For troubleshooting information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/troubleshooting-required-status-checks)."
+
+## Block force pushes
+
+You can prevent users from force pushing to the targeted branches or tags. This rule is enabled by default.
+
+If someone force pushes to a branch or tag, commits that other collaborators have based their work on may be removed from the history of the branch or tag. This may lead to merge conflicts or corrupted pull requests. Force pushing can also be used to delete branches or point a branch to commits that were not approved in a pull request.
+
+Enabling force pushes will not override any other rules. For example, if a branch requires a linear commit history, you cannot force push merge commits to that branch.
+
+{% ifversion ghes or ghae %}You cannot enable force pushes for a branch if a site administrator has blocked force pushes to all branches in your repository. For more information, see "[AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise)."
+
+If a site administrator has blocked force pushes to the default branch only, you can still enable force pushes for any other branch or tag.{% endif %}
+
+{% ifversion repo-rules-enterprise %}
+
+## Metadata restrictions
+
+{% note %}
+
+**Notes:**
+
+- Adding restrictions for commit metadata may impact the experience of people contributing to your repository.
+- Metadata restrictions are intended to increase consistency between commits in your repository. They are not intended to replace security measures such as requiring code review via pull requests.
+
+{% endnote %}
+
+Organizations on a {% data variables.product.prodname_enterprise %} plan can access additional rules to control how commit metadata must be formatted. You can use literal strings or regular expression syntax to define a pattern that the commit metadata must conform to. For example, you can require that commit messages contain a {% data variables.product.company_short %} issue number, or that the committer or author has an email address ending in `@octoorg.com`. You can also control the format of new branch names and tag names. For a selection of useful regular expressions for commit metadata, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository#using-regular-expressions-for-commit-metadata)."
+
+If a contributor tries to update a branch or tag with a commit that doesn't meet your requirements, the contributor will see an error telling them what was wrong with their commit. This error can appear both in the command line, when the user pushes, and on {% data variables.product.prodname_dotcom_the_website %}, when the user tries to make a commit or merge a pull request. Commits are immutable in Git: once a contributor has created a commit, they cannot edit the commit's metadata, so they may need to perform a rebase to rewrite their commit history with new commits before they can successfully contribute their work to the repository.
+
+Metadata restrictions are useful for enforcing consistency between the commits in a branch's history. This can be useful for enforcing adherence to best practices, such as the [Conventional Commits](https://www.conventionalcommits.org/) specification, or for integrating with tooling that relies on commit metadata. For example, it is easier to run scripts based on the contents of a commit message if each message conforms to a predictable format. {% ifversion ghes %}You may want to use metadata restrictions as an alternative for setting up custom pre-receive hook scripts. For more information, see "[AUTOTITLE
+(/admin/policies/enforcing-policy-with-pre-receive-hooks/about-pre-receive-hooks)."{% endif %}
+
+### Important considerations for metadata restrictions
+
+Metadata restrictions block "ref updates." If a contributor pushes work that includes a commit that doesn't meet the requirements, the push is not rejected, but the branch or tag they are targeting is not updated. Technically, the commits still enter your repository: the commits will be "retrievable" (you can navigate to them in your repository), but not "reachable" (they are not connected to the history of a branch or tag). If the contributor's push also includes work on other branches or tags, with commits that meet the requirements of those branches or tags, then those references will be successfully updated.
+
+Metadata restrictions can increase friction for people contributing to a repository. Generally, if you impose metadata restrictions, you should do so on a limited set of branches to avoid impacting contributors' daily work. For example, instead of requiring consistent commit messages on any topic branch that a contributor might work on, you should require consistent commit messages on `main`, then require pull requests and squash merges into `main`. Contributors will only have to think about the restrictions when they merge a pull request into `main`, not for every commit they make. You can also configure the default message for the squash merge to use the required format. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests)."
+
+When you add metadata restrictions to an existing branch or tag, the rules are enforced for new commits pushed to the branch or tag from that point forward, but they are not enforced against the existing history of the branch or tag. However, if you create a new branch or tag that is targeted by a metadata restriction, the rules are enforced against its entire history.
+
+To understand more about how metadata restrictions work, consider the following example. In this example, you are adding a restriction to ensure that every commit message starts with an issue number. The following points outline some of the effects of adding this restriction.
+
+- You add the restriction to a ruleset targeting your `main` branch. You can add the restriction without changing the existing history of the branch, even if the history contains commits that do not meet the new requirement. However, from now on, new commits pushed to `main` will need to meet the new requirement.
+- You have an existing branch pushed to the repository, called `new-feature`. The commits that exist in the `new-feature` branch, but not in `main`, will be evaluated if you try to merge the branch into `main`. To merge the branch, you may need to use a squash merge with an appropriate commit message.
+- You update the ruleset targeting `main` so that any branches that match the pattern `release-*` are also targeted. Then, you try to create a new branch from `main`, called `release-3.2`. You won't be able to create this new branch, because for the creation of the new branch the metadata requirement is evaluated against the entire commit history of `main`.
+
+These considerations may or may not pose a problem, depending on how you expect contributors to work in your repository and who has bypass permissions in the ruleset.
+
+{% endif %}

content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/index.md

@@ -0,0 +1,16 @@
+---
+title: Managing rulesets for a repository
+intro: 'Rulesets help you to control how people can interact with branches and tags in a repository.'
+product: '{% data reusables.gated-features.repo-rules %}'
+versions:
+  feature: repo-rules
+topics:
+  - Repositories
+children:
+  - /about-rulesets
+  - /managing-rulesets-for-a-repository
+  - /available-rules-for-rulesets
+  - /troubleshooting-rules
+shortTitle: Manage rulesets
+---
+

content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository.md

@@ -0,0 +1,106 @@
+---
+title: Managing rulesets for a repository
+intro: 'You can add rulesets to a repository to control how people can interact with specific branches and tags.'
+product: '{% data reusables.gated-features.repo-rules %}'
+versions:
+  feature: repo-rules
+permissions: '{% data reusables.repositories.repo-rules-permissions %}'
+topics:
+  - Repositories
+shortTitle: Manage a ruleset
+---
+
+{% data reusables.repositories.rulesets-public-beta %}
+
+You can create rulesets to control how users can interact with selected branches and tags in a repository. When you create a ruleset, you can allow certain users to bypass the rules in the ruleset. This can be users with certain permissions, specific teams, or {% data variables.product.prodname_github_apps %}. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
+
+{% data reusables.repositories.rulesets-sudo-mode %}
+
+{% ifversion repo-rules-enterprise %}
+{% tip %}
+
+**Tip:** If you're the owner of an organization, you can create rulesets at the organization level. You can apply these rulesets to specific repositories in your organization, and to specific branches in those repositories. For more information, see "[AUTOTITLE](/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization)."
+
+{% endtip %}
+{% endif %}
+
+## Viewing rulesets for a repository
+
+Anyone with read access to a repository can view the rulesets targeting the repository. This can be useful if you want to know why you can't commit to a branch. On the "Rulesets" page, you can view the active rulesets targeting a certain branch or tag. {% ifversion repo-rules-enterprise %}You will also see rulesets running in "Evaluate" mode, which are not enforced.{% endif %}
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.navigate-to-branches %}
+1. To the left of the branch, click {% octicon "shield-lock" aria-label="This branch is protected" %}.
+
+   ![Screenshot of a list of branches in a repository. Next to the "main" branch, an icon of a shield with a keyhole is highlighted with an orange outline.](/assets/images/help/repository/view-branch-rules.png)
+1. Optionally, to view the rulesets for another branch or tag, use the branch selector dropdown menu.
+
+   ![Screenshot of the "Rulesets" page. Above a ruleset, a dropdown menu, labeled with a branch icon and "team-test," is highlighted with an orange outline.](/assets/images/help/repository/rulesets-branch-selector.png)
+1. Click the name of the ruleset you want to view.
+
+## Creating a ruleset
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.sidebar-settings %}
+{% data reusables.repositories.repo-rulesets-settings %}
+{% data reusables.repositories.create-ruleset-step %}
+{% data reusables.repositories.rulesets-general-step %}
+{% data reusables.repositories.rulesets-bypass-step %}
+{% data reusables.repositories.rulesets-target-branches %}
+{% data reusables.repositories.rulesets-protections-step %}{% ifversion repo-rules-enterprise %}
+{% data reusables.repositories.rulesets-metadata-step %}{% endif %}
+{% data reusables.repositories.rulesets-create-step %}
+
+## Editing a ruleset
+
+{% ifversion repo-rules-enterprise %}
+{% note %}
+
+**Note:** If a ruleset was created at the organization level, you cannot edit the ruleset from the repository's settings. If you have permission to edit the ruleset, you can do so in your organization's settings. For more information, see "[AUTOTITLE](/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization#editing-a-ruleset)."
+
+{% endnote %}
+{% endif %}
+
+{% data reusables.repositories.about-editing-rulesets %}
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.sidebar-settings %}
+{% data reusables.repositories.repo-rulesets-settings %}
+{% data reusables.repositories.edit-ruleset-steps %}
+
+## Deleting a ruleset
+
+{% data reusables.repositories.deleting-ruleset-tip %}
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.sidebar-settings %}
+{% data reusables.repositories.repo-rulesets-settings %}
+{% data reusables.repositories.delete-ruleset-steps %}
+
+{% ifversion repo-rules-enterprise %}
+
+## Viewing insights for rulesets
+
+You can view insights for rulesets to see how rulesets are affecting a repository. {% data reusables.repositories.about-ruleset-insights %}
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.sidebar-settings %}
+1. In the left sidebar, under "Code and automation," click **Rules**, then click **Insights**.
+
+   ![Screenshot of the sidebar of the "Settings" page for a repository. The "Rules" sub-menu is expanded, and the "Insights" option is outlined in orange.](/assets/images/help/repository/ruleset-insights.png)
+1. On the "Rule Insights" page, use the dropdown menus at the top of the page to filter the actions by ruleset, branch, actor, and time period.
+{% data reusables.repositories.rulesets-view-rule-runs %}
+
+{% endif %}
+
+## Using `fnmatch` syntax
+
+{% data reusables.repositories.rulesets-fnmatch %}
+
+{% ifversion repo-rules-enterprise %}
+
+## Using regular expressions for commit metadata
+
+{% data reusables.repositories.rulesets-commit-regex %}
+
+{% endif %}

content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/troubleshooting-rules.md

@@ -0,0 +1,18 @@
+---
+title: Troubleshooting rules
+intro: 'Learn how to troubleshoot rulesets when you''re contributing to a repository.'
+product: '{% data reusables.gated-features.repo-rules %}'
+versions:
+  feature: repo-rules
+topics:
+  - Repositories
+shortTitle: Troubleshooting
+---
+
+{% data reusables.repositories.rulesets-public-beta %}
+
+If you cannot perform an action in a repository and want to know why, you can view the active rulesets targeting the branch or tag you're working with. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository#viewing-rulesets-for-a-repository)."
+
+Depending on which rules are active, you may need to edit your commit history locally before you can push your commits to the remote branch. For example, if a branch requires commits to be signed, you can update your signing settings, then use an interactive rebase on your local branch to rewrite your Git history with signed commits. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-signed-commits)" and "[AUTOTITLE](/get-started/using-git/using-git-rebase-on-the-command-line)."
+
+If a branch or tag is targeted by rules restricting the metadata of commits, your commits may be rejected if part of the commit's metadata does not match a certain pattern. For example, you might need to add an issue number to the start of your commit message, or change the name of a new branch or tag you're trying to push to the repository. If your commits are rejected, you will see a message telling you the pattern the relevant metadata needs to match. As with signed commits, you may need to perform a rebase to squash the commits or rewrite each commit individually. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#metadata-restrictions)."

content/repositories/creating-and-managing-repositories/best-practices-for-repositories.md

@@ -21,7 +21,7 @@ To make it easier for people to understand and navigate your work, we recommend
 
 To streamline collaboration, we recommend that regular collaborators work from a single repository, creating pull requests between branches instead of between repositories. Forking is best suited for accepting contributions from people that are unaffiliated with a project, such as open-source contributors.
 
-To maintain quality of important branches, such as `main`, while using a branching workflow, you can use protected branches with required status checks and pull request reviews. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)."
+To maintain quality of important branches, such as `main`, while using a branching workflow, you can use protected branches with required status checks and pull request reviews. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."
 
 ## Use {% data variables.large_files.product_name_long %}
 

content/repositories/index.md

@@ -12,13 +12,13 @@ featuredLinks:
     - /repositories/working-with-files/managing-files/adding-a-file-to-a-repository
     - /repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository
   popular:
-    - /repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches
+    - /repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
     - /repositories/releasing-projects-on-github/about-releases
     - /repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes
     - /repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
   guideCards:
     - /repositories/creating-and-managing-repositories/deleting-a-repository
-    - /repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule
+    - /repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule
     - /repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility
 changelog:
   label: repos

content/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners.md

@@ -23,7 +23,7 @@ The people you choose as code owners must have write permissions for the reposit
 
 Code owners are automatically requested for review when someone opens a pull request that modifies code that they own. Code owners are not automatically requested to review draft pull requests. For more information about draft pull requests, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests)." When you mark a draft pull request as ready for review, code owners are automatically notified. If you convert a pull request to a draft, people who are already subscribed to notifications are not automatically unsubscribed. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request)."
 
-When someone with admin or owner permissions has enabled required reviews, they also can optionally require approval from a code owner before the author can merge a pull request in the repository. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging)."
+When someone with admin or owner permissions has enabled required reviews, they also can optionally require approval from a code owner before the author can merge a pull request in the repository. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-pull-request-reviews-before-merging)."
 
 If a file has a code owner, you can see who the code owner is before you open a pull request. In the repository, you can browse to the file and hover over {% octicon "shield-lock" aria-label="The edit icon" %}.
 
@@ -132,7 +132,7 @@ apps/ @octocat
 ```
 
 ## CODEOWNERS and branch protection
-Repository owners can add branch protection rules to ensure that changed code is reviewed by the owners of the changed files. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)."
+Repository owners can add branch protection rules to ensure that changed code is reviewed by the owners of the changed files. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."
 
 ## Further reading
 

content/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/customizing-your-repositorys-social-media-preview.md

@@ -18,7 +18,7 @@ Until you add an image, repository links expand to show basic information about
 
 ## Adding an image to customize the social media preview of your repository
 
-{% ifversion not ghae %}You can upload an image to a private repository, but your image can only be shared from a public repository.{% endif %}
+{% ifversion repo-rules %}You can upload an image to a public repository, or to a private repository to which you have previously uploaded an image. Your image can only be shared from a public repository.{% else %}You can upload an image to a private repository, but your image can only be shared from a public repository.{% endif %}
 
 {% tip %}
 

data/features/repo-rules-enterprise.yml

@@ -0,0 +1,6 @@
+# Reference: #9228
+# Public beta for repository rulesets.
+# Feature flag for enterprise-only features (metadata restrictions, setting rulesets at org level, ruleset insights)
+versions:
+  ghec: '*'
+  ghes: '>3.9'

data/features/repo-rules.yml

@@ -0,0 +1,6 @@
+# Reference: #9228
+# Public beta for repository rulesets
+versions:
+  fpt: '*'
+  ghec: '*'
+  ghes: '>3.9'

data/release-notes/enterprise-server/3-4/0-rc1.yml

@@ -137,7 +137,7 @@ sections:
         - When configuring protected branches, you can now enforce that a required status check is provided by a specific {% data variables.product.prodname_github_app %}. If a status is then provided by a different application, or by a user via a commit status, merging is prevented. This ensures all changes are validated by the intended application. For more information, see the "[{% data variables.product.prodname_dotcom %} changelog](https://github.blog/changelog/2021-12-01-ensure-required-status-checks-provided-by-the-intended-app/)."
 
         # https://github.com/github/releases/issues/1911
-        - Only users with administrator permissions are now able to rename protected branches and modify branch protection rules. Previously, with the exception of the default branch, a collaborator could rename a branch and consequently any non-wildcard branch protection rules that applied to that branch were also renamed. For more information, see "[Renaming a branch](/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+        - Only users with administrator permissions are now able to rename protected branches and modify branch protection rules. Previously, with the exception of the default branch, a collaborator could rename a branch and consequently any non-wildcard branch protection rules that applied to that branch were also renamed. For more information, see "[Renaming a branch](/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
 
         # https://github.com/github/releases/issues/1845
         - Administrators can now allow only specific users and teams to bypass pull request requirements. For more information, see the "[{% data variables.product.prodname_dotcom %} changelog](https://github.blog/changelog/2021-11-19-allow-bypassing-required-pull-requests/)."

data/release-notes/enterprise-server/3-4/0.yml

@@ -145,7 +145,7 @@ sections:
         - When configuring protected branches, you can now enforce that a required status check is provided by a specific {% data variables.product.prodname_github_app %}. If a status is then provided by a different application, or by a user via a commit status, merging is prevented. This ensures all changes are validated by the intended application. For more information, see the "[{% data variables.product.prodname_dotcom %} changelog](https://github.blog/changelog/2021-12-01-ensure-required-status-checks-provided-by-the-intended-app/)."
 
         # https://github.com/github/releases/issues/1911
-        - Only users with administrator permissions are now able to rename protected branches and modify branch protection rules. Previously, with the exception of the default branch, a collaborator could rename a branch and consequently any non-wildcard branch protection rules that applied to that branch were also renamed. For more information, see "[Renaming a branch](/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+        - Only users with administrator permissions are now able to rename protected branches and modify branch protection rules. Previously, with the exception of the default branch, a collaborator could rename a branch and consequently any non-wildcard branch protection rules that applied to that branch were also renamed. For more information, see "[Renaming a branch](/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
 
         # https://github.com/github/releases/issues/1845
         - Administrators can now allow only specific users and teams to bypass pull request requirements. For more information, see the "[{% data variables.product.prodname_dotcom %} changelog](https://github.blog/changelog/2021-11-19-allow-bypassing-required-pull-requests/)."

data/release-notes/enterprise-server/3-5/0-rc1.yml

@@ -92,7 +92,7 @@ sections:
       notes:
         # https://github.com/github/releases/issues/1963
         - |
-          You can now configure GitHub Enterprise Server to automatically sign commits made in the web interface, such as from editing a file or merging a pull request. Signed commits increase confidence that changes come from trusted sources. This feature allows the [Require signed commits](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-signed-commits) branch protection setting to block unsigned commits from entering a repository, while allowing entry of signed commits – even those made in the web interface. For more information, see "[Configuring web commit signing](/admin/configuration/configuring-your-enterprise/configuring-web-commit-signing)."
+          You can now configure GitHub Enterprise Server to automatically sign commits made in the web interface, such as from editing a file or merging a pull request. Signed commits increase confidence that changes come from trusted sources. This feature allows the [Require signed commits](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-signed-commits) branch protection setting to block unsigned commits from entering a repository, while allowing entry of signed commits – even those made in the web interface. For more information, see "[Configuring web commit signing](/admin/configuration/configuring-your-enterprise/configuring-web-commit-signing)."
 
     - heading: Sync license usage any time
       notes:

data/release-notes/enterprise-server/3-5/0.yml

@@ -83,7 +83,7 @@ sections:
       notes:
         # https://github.com/github/releases/issues/1963
         - |
-          You can now configure GitHub Enterprise Server to automatically sign commits made in the web interface, such as from editing a file or merging a pull request. Signed commits increase confidence that changes come from trusted sources. This feature allows the [Require signed commits](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-signed-commits) branch protection setting to block unsigned commits from entering a repository, while allowing entry of signed commits – even those made in the web interface. For more information, see "[Configuring web commit signing](/admin/configuration/configuring-your-enterprise/configuring-web-commit-signing)."
+          You can now configure GitHub Enterprise Server to automatically sign commits made in the web interface, such as from editing a file or merging a pull request. Signed commits increase confidence that changes come from trusted sources. This feature allows the [Require signed commits](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-signed-commits) branch protection setting to block unsigned commits from entering a repository, while allowing entry of signed commits – even those made in the web interface. For more information, see "[Configuring web commit signing](/admin/configuration/configuring-your-enterprise/configuring-web-commit-signing)."
 
     - heading: Sync license usage any time
       notes:

data/release-notes/enterprise-server/3-6/0-rc1.yml

@@ -205,7 +205,7 @@ sections:
         # https://github.com/github/releases/issues/1973
         - |
           Users can block creation of branches that match a configured name pattern with the **Restrict pushes that create matching branches** branch protection rule. For example, if a repository's default branch changes from `master` to `main`, a repository administrator can prevent any subsequent creation or push of the `master` branch. For more information, see 
-          "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#restrict-who-can-push-to-matching-branches)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule#creating-a-branch-protection-rule)."
+          "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#restrict-who-can-push-to-matching-branches)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule#creating-a-branch-protection-rule)."
 
         # https://github.com/github/releases/issues/2179
         - |
@@ -224,7 +224,7 @@ sections:
 
         # https://github.com/github/releases/issues/2093
         - |
-          Users can require a successful deployment of a branch before anyone can merge the pull request associated with the branch. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-deployments-to-succeed-before-merging)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+          Users can require a successful deployment of a branch before anyone can merge the pull request associated with the branch. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-deployments-to-succeed-before-merging)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
 
         # https://github.com/github/releases/issues/2073
         - |
@@ -232,7 +232,7 @@ sections:
 
         # https://github.com/github/releases/issues/2173
         - |
-          Users can grant exceptions to GitHub Apps for any branch protection rule that supports exceptions. For more information, see "[About apps](/developers/apps/getting-started-with-apps/about-apps)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+          Users can grant exceptions to GitHub Apps for any branch protection rule that supports exceptions. For more information, see "[About apps](/developers/apps/getting-started-with-apps/about-apps)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
 
     - heading: Commits
       notes:

data/release-notes/enterprise-server/3-6/0.yml

@@ -215,7 +215,7 @@ sections:
 
         # https://github.com/github/releases/issues/2093
         - |
-          Users can require a successful deployment of a branch before anyone can merge the pull request associated with the branch. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-deployments-to-succeed-before-merging)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+          Users can require a successful deployment of a branch before anyone can merge the pull request associated with the branch. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-deployments-to-succeed-before-merging)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
 
         # https://github.com/github/releases/issues/2073
         - |
@@ -223,7 +223,7 @@ sections:
 
         # https://github.com/github/releases/issues/2173
         - |
-          Users can grant exceptions to GitHub Apps for any branch protection rule that supports exceptions. For more information, see "[About apps](/developers/apps/getting-started-with-apps/about-apps)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+          Users can grant exceptions to GitHub Apps for any branch protection rule that supports exceptions. For more information, see "[About apps](/developers/apps/getting-started-with-apps/about-apps)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
 
     - heading: Commits
       notes:

data/release-notes/enterprise-server/3-7/0-rc1.yml

@@ -49,7 +49,7 @@ sections:
 
         # https://github.com/github/releases/issues/2373
         - |
-           Users on an instance with a GitHub Advanced Security license can view and comment on code scanning alerts in their repository within a pull request's **Conversation** tab. If the **Require conversation resolution before merging** branch protection rule is enabled for the repository, all comments on these code scanning alerts must be resolved before a user merges the pull request. For more information, see "[About code scanning](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning#about-code-scanning)," "[About pull request reviews](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews)," and "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-conversation-resolution-before-merging)."
+           Users on an instance with a GitHub Advanced Security license can view and comment on code scanning alerts in their repository within a pull request's **Conversation** tab. If the **Require conversation resolution before merging** branch protection rule is enabled for the repository, all comments on these code scanning alerts must be resolved before a user merges the pull request. For more information, see "[About code scanning](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning#about-code-scanning)," "[About pull request reviews](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews)," and "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-conversation-resolution-before-merging)."
 
         # https://github.com/github/releases/issues/2388
         - |
@@ -254,7 +254,7 @@ sections:
 
         # https://github.com/github/releases/issues/1973
         - |
-          Repository administrators can block the creation of branches that match a configured name pattern with the **Restrict pushes that create matching branches** branch protection rule. For example, if a repository's default branch changes from `master` to `main`, a repository administrator can prevent any subsequent creation or push of the `master` branch. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#restrict-who-can-push-to-matching-branches)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule#creating-a-branch-protection-rule)."
+          Repository administrators can block the creation of branches that match a configured name pattern with the **Restrict pushes that create matching branches** branch protection rule. For example, if a repository's default branch changes from `master` to `main`, a repository administrator can prevent any subsequent creation or push of the `master` branch. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#restrict-who-can-push-to-matching-branches)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule#creating-a-branch-protection-rule)."
 
         # https://github.com/github/releases/issues/2105
         - |

data/release-notes/enterprise-server/3-7/0.yml

@@ -40,7 +40,7 @@ sections:
       notes:
         # https://github.com/github/releases/issues/2373
         - |
-           Users on an instance with a GitHub Advanced Security license can view and comment on code scanning alerts in their repository within a pull request's **Conversation** tab. If the **Require conversation resolution before merging** branch protection rule is enabled for the repository, all comments on these code scanning alerts must be resolved before a user merges the pull request. For more information, see "[About code scanning](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning#about-code-scanning)," "[About pull request reviews](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews)," and "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-conversation-resolution-before-merging)."
+           Users on an instance with a GitHub Advanced Security license can view and comment on code scanning alerts in their repository within a pull request's **Conversation** tab. If the **Require conversation resolution before merging** branch protection rule is enabled for the repository, all comments on these code scanning alerts must be resolved before a user merges the pull request. For more information, see "[About code scanning](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning#about-code-scanning)," "[About pull request reviews](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews)," and "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-conversation-resolution-before-merging)."
 
         # https://github.com/github/releases/issues/2388
         - |
@@ -253,7 +253,7 @@ sections:
 
         # https://github.com/github/releases/issues/1973
         - |
-          Repository administrators can block the creation of branches that match a configured name pattern with the **Restrict pushes that create matching branches** branch protection rule. For example, if a repository's default branch changes from `master` to `main`, a repository administrator can prevent any subsequent creation or push of the `master` branch. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#restrict-who-can-push-to-matching-branches)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule#creating-a-branch-protection-rule)."
+          Repository administrators can block the creation of branches that match a configured name pattern with the **Restrict pushes that create matching branches** branch protection rule. For example, if a repository's default branch changes from `master` to `main`, a repository administrator can prevent any subsequent creation or push of the `master` branch. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#restrict-who-can-push-to-matching-branches)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule#creating-a-branch-protection-rule)."
 
         # https://github.com/github/releases/issues/2105
         - |

data/release-notes/enterprise-server/3-8/0-rc1.yml

@@ -255,12 +255,12 @@ sections:
       notes:
         # https://github.com/github/releases/issues/2175
         - |
-          To avoid providing full administrative access to a repository when unnecessary, repository administrators can create a custom role that allows users to bypass branch protections. To enforce branch protections for all users with administrative access or bypass permissions, administrators can enable **Do not allow bypassing the above settings**. For more information, see "[Managing custom repository roles for an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/managing-custom-repository-roles-for-an-organization#repository)" and "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#do-not-allow-bypassing-the-above-settings)."
+          To avoid providing full administrative access to a repository when unnecessary, repository administrators can create a custom role that allows users to bypass branch protections. To enforce branch protections for all users with administrative access or bypass permissions, administrators can enable **Do not allow bypassing the above settings**. For more information, see "[Managing custom repository roles for an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/managing-custom-repository-roles-for-an-organization#repository)" and "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#do-not-allow-bypassing-the-above-settings)."
 
         # https://github.com/github/releases/issues/2610
         # https://github.com/github/releases/issues/2626
         - |
-          Repository administrators can ensure the security and stability of branches by requiring pull request approval by someone other than the last pusher, or by locking the branch. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#about-branch-protection-settings)."
+          Repository administrators can ensure the security and stability of branches by requiring pull request approval by someone other than the last pusher, or by locking the branch. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#about-branch-protection-settings)."
 
         # https://github.com/github/releases/issues/2666
         - |

data/release-notes/enterprise-server/3-8/0.yml

@@ -249,12 +249,12 @@ sections:
       notes:
         # https://github.com/github/releases/issues/2175
         - |
-          To avoid providing full administrative access to a repository when unnecessary, repository administrators can create a custom role that allows users to bypass branch protections. To enforce branch protections for all users with administrative access or bypass permissions, administrators can enable **Do not allow bypassing the above settings**. For more information, see "[Managing custom repository roles for an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/managing-custom-repository-roles-for-an-organization#repository)" and "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#do-not-allow-bypassing-the-above-settings)."
+          To avoid providing full administrative access to a repository when unnecessary, repository administrators can create a custom role that allows users to bypass branch protections. To enforce branch protections for all users with administrative access or bypass permissions, administrators can enable **Do not allow bypassing the above settings**. For more information, see "[Managing custom repository roles for an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/managing-custom-repository-roles-for-an-organization#repository)" and "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#do-not-allow-bypassing-the-above-settings)."
 
         # https://github.com/github/releases/issues/2610
         # https://github.com/github/releases/issues/2626
         - |
-          Repository administrators can ensure the security and stability of branches by requiring pull request approval by someone other than the last pusher, or by locking the branch. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#about-branch-protection-settings)."
+          Repository administrators can ensure the security and stability of branches by requiring pull request approval by someone other than the last pusher, or by locking the branch. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#about-branch-protection-settings)."
 
         # https://github.com/github/releases/issues/2666
         - |

data/release-notes/github-ae/3-2/0.yml

@@ -75,7 +75,7 @@ sections:
         - |
           With the [latest version of Octicons](https://github.com/primer/octicons/releases), the states of issues and pull requests are now more visually distinct so you can scan status more easily. For more information, see [{% data variables.product.prodname_blog %}](https://github.blog/changelog/2021-06-08-new-issue-and-pull-request-state-icons/).
         - |
-          You can now see all pull request review comments in the **Files** tab for a pull request by selecting the  **Conversations** drop-down. You can also require that all pull request review comments are resolved before anyone merges the pull request. For more information, see "[About pull request reviews](/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews#discovering-and-navigating-conversations)" and "[About protected branches](/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-conversation-resolution-before-merging)." For more information about management of branch protection settings with the API, see "[Branches](/rest/reference/branches#get-branch-protection)" in the REST API documentation and "[Mutations](/graphql/reference/mutations#createbranchprotectionrule)" in the GraphQL API documentation.
+          You can now see all pull request review comments in the **Files** tab for a pull request by selecting the  **Conversations** drop-down. You can also require that all pull request review comments are resolved before anyone merges the pull request. For more information, see "[About pull request reviews](/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews#discovering-and-navigating-conversations)" and "[About protected branches](/github/administering-a-repository/managing-protected-branches/about-protected-branches#require-conversation-resolution-before-merging)." For more information about management of branch protection settings with the API, see "[Branches](/rest/reference/branches#get-branch-protection)" in the REST API documentation and "[Mutations](/graphql/reference/mutations#createbranchprotectionrule)" in the GraphQL API documentation.
         - |
           You can now upload video files everywhere you write Markdown on {% data variables.product.product_name %}. Share demos, show reproduction steps, and more in issue and pull request comments, as well as in Markdown files within repositories, such as READMEs. For more information, see "[Attaching files](/github/writing-on-github/working-with-advanced-formatting/attaching-files)."
         - |

data/release-notes/github-ae/3-4/0.yml

@@ -91,13 +91,13 @@ sections:
     - heading: 'Repositories'
       notes:
         - |
-          Users with admin access to a repository can rename branches that are protected by branch protection rules. For more information, see "[Renaming a branch](/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+          Users with admin access to a repository can rename branches that are protected by branch protection rules. For more information, see "[Renaming a branch](/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
         - |
-          Instead of allowing all or no users to force push, people with admin access to a repository can choose who can force push to the repository. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#allow-force-pushes)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+          Instead of allowing all or no users to force push, people with admin access to a repository can choose who can force push to the repository. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#allow-force-pushes)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
         - |
-          Users with admin access to a repository can require that all changes to a protected branch are made using a pull request, but without requiring reviews. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+          Users with admin access to a repository can require that all changes to a protected branch are made using a pull request, but without requiring reviews. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-pull-request-reviews-before-merging)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
         - |
-          Users with admin access to a repository can allow specific users and teams to bypass pull request requirements. For more information, see "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+          Users with admin access to a repository can allow specific users and teams to bypass pull request requirements. For more information, see "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
         - |
           Users can use single-character prefixes for custom autolinks. Autolink prefixes also allow `.`, `-`, `_`, `+`, `=`, `:`, `/`, and `#` characters, as well as alphanumerics. For more information, see "[Configuring autolinks to reference external resources](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-autolinks-to-reference-external-resources)."
 
@@ -144,7 +144,7 @@ sections:
     - heading: 'GitHub Apps'
       notes:
         - |
-          To ensures all changes are validated by the intended app, users can now control which GitHub App a required status check is provided by. If status is then provided by a different app or by a user via a commit status, merging will be prevented. Existing required status checks will continue to accept status from any app, but can be updated to only accept status from a specific app. Newly-added required status checks will default to the app that most recently reported the status, but you can choose a different app or allow any app to provide the status. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging)" and "[Editing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule#editing-a-branch-protection-rule)."
+          To ensures all changes are validated by the intended app, users can now control which GitHub App a required status check is provided by. If status is then provided by a different app or by a user via a commit status, merging will be prevented. Existing required status checks will continue to accept status from any app, but can be updated to only accept status from a specific app. Newly-added required status checks will default to the app that most recently reported the status, but you can choose a different app or allow any app to provide the status. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging)" and "[Editing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule#editing-a-branch-protection-rule)."
 
     - heading: 'Webhooks'
       notes:

data/release-notes/github-ae/3-6/0.yml

@@ -206,7 +206,7 @@ sections:
           When a user renames or moves a file to a new directory, if at least half of the file's contents are identical, the commit history indicates that the file was renamed, similar to `git log --follow`. For more information, see the [GitHub Blog](https://github.blog/changelog/2022-06-06-view-commit-history-across-file-renames-and-moves/).
         # https://github.com/github/releases/issues/2093
         - |
-          Users can require a successful deployment of a branch before anyone can merge the pull request associated with the branch. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-deployments-to-succeed-before-merging)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+          Users can require a successful deployment of a branch before anyone can merge the pull request associated with the branch. For more information, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-deployments-to-succeed-before-merging)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
         # https://github.com/github/releases/issues/1793
         - |
           Repository administrators can now configure tag protection rules to protect a repository's tags. Once protected by a tag protection rule, tags matching a specified name pattern can only be created and deleted by users with maintain or admin access to the repository. For more information, see "[Configuring tag protection rules](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-tag-protection-rules)."
@@ -215,7 +215,7 @@ sections:
           Users can ignore revisions in the blame view by creating a `.git-blame-ignore-revs` file in the root of a repository. For more information, see "[Viewing a file](/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view)."
         # https://github.com/github/releases/issues/2173
         - |
-          Users can grant exceptions to GitHub Apps for any branch protection rule that supports exceptions. For more information, see "[About apps](/developers/apps/getting-started-with-apps/about-apps)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+          Users can grant exceptions to GitHub Apps for any branch protection rule that supports exceptions. For more information, see "[About apps](/developers/apps/getting-started-with-apps/about-apps)" and "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
 
     - heading: 'Commits'
       notes:

data/reusables/actions/workflows/required-workflow-prerequisites.md

@@ -1,5 +1,5 @@
 * {% data variables.product.prodname_actions %} must be enabled for a repository in the organization's settings in order for required workflows to run. Once enabled at an organization-level, required workflows will run even when {% data variables.product.prodname_actions %} is disabled in the repository's settings. For more information on managing {% data variables.product.prodname_actions %} in your organization's repositories, see "[AUTOTITLE](/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#managing-github-actions-permissions-for-your-organization)."
-* Required workflows are available for organizations and only in repositories where the organization's plan supports required status checks. If required status checks are not supported, the workflow will still run, but it will not be a required check and will not block merging. For more information about support for required status checks, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)."
+* Required workflows are available for organizations and only in repositories where the organization's plan supports required status checks. If required status checks are not supported, the workflow will still run, but it will not be a required check and will not block merging. For more information about support for required status checks, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."
 * The repository's default branch must match the organization's default branch setting in order for required workflows to run as required status checks. If the default branch names do not match, the workflow will still run, but it will not be a required check. For more information about managing default branch names, see "[AUTOTITLE](/organizations/managing-organization-settings/managing-the-default-branch-name-for-repositories-in-your-organization)" and "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/changing-the-default-branch)."
 * For required workflows to run, the pull request's source repository must be in the same organization as the target repository. {% data variables.product.product_name %} will source the required workflow from {% ifversion actions-required-workflow-improvements %}a specified branch, tag, or commit SHA {% else %}the HEAD commit of the default branch {% endif %}from the repository containing the workflow.
 * Secrets used in a required workflow should be created at either the organization level or in the target repositories.

data/reusables/actions/workflows/section-triggering-a-workflow-paths.md

@@ -20,7 +20,7 @@ on:
 
 {% note %}
 
-**Note:** If a workflow is skipped due to [path filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), [branch filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore) or a [commit message](/actions/managing-workflow-runs/skipping-workflow-runs), then checks associated with that workflow will remain in a "Pending" state. A pull request that requires those checks to be successful will be blocked from merging. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks#handling-skipped-but-required-checks)."
+**Note:** If a workflow is skipped due to [path filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), [branch filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore) or a [commit message](/actions/managing-workflow-runs/skipping-workflow-runs), then checks associated with that workflow will remain in a "Pending" state. A pull request that requires those checks to be successful will be blocked from merging. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/troubleshooting-required-status-checks#handling-skipped-but-required-checks)."
 
 {% endnote %}
 

data/reusables/desktop/protected-branches.md

@@ -1 +1 @@
-Repository administrators can enable protections on a branch. If you're working on a branch that's protected, you won't be able to delete or force push to the branch. Repository administrators can enable other protected branch settings to enforce specific workflows before a branch can be merged. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)."
+Repository administrators can enable protections on a branch. If you're working on a branch that's protected, you won't be able to delete or force push to the branch. Repository administrators can enable other protected branch settings to enforce specific workflows before a branch can be merged. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."

data/reusables/gated-features/repo-rules.md

@@ -0,0 +1 @@
+Rulesets are available in public repositories with {% data variables.product.prodname_free_user %} and {% data variables.product.prodname_free_team %} for organizations, and in public and private repositories with {% data variables.product.prodname_pro %}, {% data variables.product.prodname_team %}, and {% data variables.product.prodname_ghe_cloud %}. {% data reusables.gated-features.more-info %}

data/reusables/organizations/access-ruleset-settings.md

@@ -0,0 +1,3 @@
+1. In the left sidebar, in the "Code, planning, and automation" section, click **{% octicon "repo" aria-hidden="true" %} Repository**, then click **Repository rulesets**.
+
+   ![Screenshot of an organization's settings page. In the sidebar, a link labeled "Repository rulesets" is outlined in orange.](/assets/images/help/organizations/repository-rulesets.png)

data/reusables/pull_requests/auto-merge-requires-branch-protection.md

@@ -1,5 +1,5 @@
 {% note %}
 
-**Note**: The option to enable auto-merge is shown only on pull requests that cannot be merged immediately. For example, when a branch protection rule enforces "Require pull request reviews before merging" or "Require status checks to pass before merging" and these conditions are not yet met. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)."
+**Note**: The option to enable auto-merge is shown only on pull requests that cannot be merged immediately. For example, when a branch protection rule enforces "Require pull request reviews before merging" or "Require status checks to pass before merging" and these conditions are not yet met. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)."
 
 {% endnote %}

data/reusables/pull_requests/required-checks-must-pass-to-merge.md

@@ -1 +1 @@
-If status checks are required for a repository, the required status checks must pass before you can merge your branch into the protected branch. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging)."
+If status checks are required for a repository, the required status checks must pass before you can merge your branch into the protected branch. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging)."

data/reusables/repositories/about-editing-rulesets.md

@@ -0,0 +1 @@
+You can edit a ruleset to change parts of the ruleset, such as the name, bypass permissions, or rules. You can also edit a ruleset to change its status, such as if you want to enable or temporarily disable a ruleset.

data/reusables/repositories/about-fnmatch.md

@@ -0,0 +1,3 @@
+Because {% data variables.product.company_short %} 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](https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch).

data/reusables/repositories/about-ruleset-insights.md

@@ -0,0 +1,9 @@
+On the "Rule Insights" page, you will see a timeline of the following user actions. You can use filters to find what you're looking for.
+
+- Actions that have been checked against one or more rulesets and passed.
+- Actions that have been checked against one or more rulesets and failed.
+- Actions where someone has bypassed one or more rulesets.
+
+If a ruleset is running in "Evaluate" mode, you can see actions that would have passed or failed if the ruleset had been active.
+
+![Screenshot of the "Rule Insights" page. Three actions are listed: one marked "pass," one marked "bypass," and one marked "fail" with an "evaluate" label.](/assets/images/help/repository/rule-insights.png)

data/reusables/repositories/create-ruleset-step.md

@@ -0,0 +1,5 @@
+1. You can create a ruleset targeting branches, or a ruleset targeting tags.
+   - To create a ruleset targeting branches, click **New branch ruleset**.
+   - To create a ruleset targeting tags, select {% octicon "triangle-down" aria-label="Open ruleset creation menu" %}, then click **New tag ruleset**.
+     
+     ![Screenshot of the "Rulesets" page. Next to the "New branch ruleset" button, a dropdown menu is expanded, with an option labeled "New tag ruleset" outlined in orange.](/assets/images/help/repository/new-tag-ruleset.png)

data/reusables/repositories/delete-ruleset-steps.md

@@ -0,0 +1,4 @@
+1. Click the name of the ruleset you want to delete.
+1. To the right of the ruleset's name, select {% octicon "kebab-horizontal" aria-label="Open additional options" %}, then click **{% octicon "trash" aria-hidden="true" %} Delete ruleset**.
+
+   ![Screenshot of the page for editing a ruleset. Below a button labeled with three dots, an option labeled "Delete ruleset" is outlined in orange.](/assets/images/help/repository/delete-ruleset.png)

data/reusables/repositories/deleting-ruleset-tip.md

@@ -0,0 +1,5 @@
+{% tip %}
+
+**Tip:** If you want to temporarily disable a ruleset but do not want to delete it, you can set the ruleset's status to "Disabled." For more information, see "[Editing a ruleset](#editing-a-ruleset)."
+
+{% endtip %}

data/reusables/repositories/edit-ruleset-steps.md

@@ -0,0 +1,3 @@
+1. On the "Rulesets" page, click the name of the ruleset you want to edit.
+1. Change the ruleset as required. For information on the available rules, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets)."
+1. At the bottom of the page, click **Save changes**.

data/reusables/repositories/protected-branches-block-web-edits-uploads.md

@@ -1,3 +1,3 @@
-If a repository has any protected branches, you can't edit or upload files in the protected branch using {% data variables.product.prodname_dotcom %}. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)."
+If a repository has any protected branches, you can't edit or upload files in the protected branch using {% data variables.product.prodname_dotcom %}. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."
 
 You can use {% data variables.product.prodname_desktop %} to move your changes to a new branch and commit them. For more information, see "[AUTOTITLE](/desktop/contributing-and-collaborating-using-github-desktop/making-changes-in-a-branch/committing-and-reviewing-changes-to-your-project)."

data/reusables/repositories/repo-rules-permissions.md

@@ -0,0 +1 @@
+Anyone with read access to a repository can view the repository's rulesets. People with admin access to a repository{% ifversion edit-repository-rules %}, or a custom role with the "edit repository rules" permission,{% endif %} can create, edit, and delete rulesets for a repository{% ifversion fpt %}.{% else %} and view ruleset insights. For more information, see "[AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-repository-roles)."{% endif %}

data/reusables/repositories/repo-rulesets-settings.md

@@ -0,0 +1,3 @@
+1. In the left sidebar, under "Code and automation," click **Rules**, then click **Rulesets**.
+
+   ![Screenshot of the sidebar of the "Settings" page for a repository. The "Rules" sub-menu is expanded, and the "Rulesets" option is outlined in orange.](/assets/images/help/repository/rulesets-settings.png)

data/reusables/repositories/ruleset-bypass.md

@@ -0,0 +1 @@
+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 {% data variables.product.prodname_github_apps %}.

data/reusables/repositories/rulesets-anyone-can-view.md

@@ -0,0 +1,5 @@
+{% note %}
+
+**Note:** Anyone with read access to a repository can view the active rulesets operating on that repository.
+
+{% endnote %}

data/reusables/repositories/rulesets-bypass-step.md

@@ -0,0 +1,7 @@
+1. Optionally, in the "Bypass list" section, add teams or {% data variables.product.prodname_github_apps %} to give them bypass permission for the ruleset.
+
+   {% note %}
+
+   **Note:** The bypass list is independent of the bypass mode. The teams and apps you add will be able to bypass the ruleset even if you set "Bypass mode" to "Not permitted."
+
+   {% endnote %}

data/reusables/repositories/rulesets-commit-regex.md

@@ -0,0 +1,75 @@
+When you add metadata restrictions, you can use regular expression syntax to define patterns that the relevant metadata, such as the commit message or the branch or tag name, must or must not match.
+
+Rulesets support RE2 syntax. For more information, see Google's [syntax guide](https://github.com/google/re2/wiki/Syntax). To validate your expressions, you can use the validator on [regex101.com](https://regex101.com/), selecting the "Golang" flavor in the left sidebar.
+
+Regular expressions consider multiple lines of text by default. For example, if you have a multiline commit message, the pattern `^ABC` will be a match if any line in the message starts with `ABC`. To match the start of the message specifically, you can start your expression with `\A`.
+
+The negative lookahead assertion, denoted `?!`, is not supported. However, for cases where you need to look for a given string that is not followed by another given string, you can use the positive lookahead assertion, denoted `?`, combined with the "Must not match a given regex pattern" requirement.
+
+{% note %}
+
+**Note:** If you require contributors to sign off on commits, this may interfere with your regular expression patterns. When someone signs off, {% data variables.product.prodname_dotcom %} adds a string like `Signed-off-by: #AUTHOR-NAME <#AUTHOR-EMAIL>` to the commit message. For more information, see "[AUTOTITLE](/organizations/managing-organization-settings/managing-the-commit-signoff-policy-for-your-organization)."
+
+{% endnote %}
+
+### Useful regular expression patterns
+
+The following examples provide useful patterns for commit metadata.
+
+#### Ensure branch names are compatible with Windows
+
+You can use the following pattern to ensure that branch names only include numbers, lowercase letters, and the characters `-` and `_`. This ensures branch names are compatible with operating systems that do not use case-sensitive file systems by default.
+
+```{:copy}
+\A[0-9a-z-_]$
+```
+
+Matches: `my-branch`
+
+Does not match: `myBranch`
+
+#### Ensure tag names use semantic versioning
+
+You can use the following pattern to ensure tag names conform to semantic versioning. For more information, see the documentation on [semver.org](https://semver.org/).
+
+```{:copy}
+^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$
+```
+
+Matches: `1.2.3`, `10.20.30`, `1.1.2-prerelease+meta`
+
+Does not match: `1.2`, `1.2-SNAPSHOT`
+
+#### Limit length of lines in commit messages
+
+The [Pro Git book](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) recommends limiting the first line of a commit message to around 50 characters.
+
+You can use the following pattern to ensure the first line in a commit message contains 50 characters or fewer.
+
+```{:copy}
+\A.{1,50}$
+```
+
+#### Ensure commit messages start with a resolution and issue number
+
+You can use the following pattern to ensure that commit messages contain the word `Resolves:` or `Fixes:`, followed by a string like `#1234`.
+
+```{:copy}
+^(Resolves|Fixes): \#[0-9]+$
+```
+
+Matches: `Fixes: #1234`
+
+Does not match: `Add conditional logic to foo.bar`
+
+#### Enforce conventional commits
+
+You can use the following pattern to ensure that commit messages conform to the Conventional Commits specification. For more information, see [conventionalcommits.org](https://www.conventionalcommits.org/).
+
+```{:copy}
+^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test){1}(\([\w\-\.]+\))?(!)?: ([\w ])+([\s\S]*)
+```
+
+Matches: `feat: allow provided config object to extend other configs`
+
+Does not match: `Add conditional logic to foo.bar`

data/reusables/repositories/rulesets-create-step.md

@@ -0,0 +1 @@
+1. To create the ruleset, click **Create**.

data/reusables/repositories/rulesets-fnmatch.md

@@ -0,0 +1,3 @@
+You can use `fnmatch` syntax to define patterns to target the names of {% ifversion repo-rules-enterprise %}branches, tags, and repositories{% else %}branches and tags{% endif %} when you create a ruleset.
+
+You can use the `*` wildcard to match any string of characters. {% data reusables.repositories.about-fnmatch %}

data/reusables/repositories/rulesets-general-step.md

@@ -0,0 +1,4 @@
+1. In the "General" section:
+   - Type a name for the ruleset.
+   - Select the enforcement status. You must set the status to **Active** if you want the ruleset to be enforced. {% ifversion repo-rules-enterprise %}Alternatively, if you set the status to **Evaluate**, the ruleset will not be enforced, but you will be able to monitor which actions would or would not violate rules on the "Rule Insights" page. For more information, see "[Viewing insights for rulesets](#viewing-insights-for-rulesets)."{% endif %}
+   - If you want repository or organization administrators to be able to bypass the rules in the ruleset, change the selection in the dropdown menu under "Bypass mode."

data/reusables/repositories/rulesets-metadata-step.md

@@ -0,0 +1,17 @@
+1. Optionally, in the "Metadata restrictions" section, to add a rule to control the metadata of commits being pushed to the branch or tag, click {% octicon "plus" aria-label="Add metadata restriction" %}.
+
+   ![Screenshot of the "Metadata restriction" section. To the right of the header, a plus icon is highlighted with an orange outline.](/assets/images/help/repository/add-metadata-restriction.png)
+
+   {% note %}
+
+   **Note:** Adding metadata restrictions can impact the experience of people contributing to your repository. Before you add metadata restrictions to a ruleset, make sure you understand their potential consequences. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#important-considerations-for-metadata-restrictions)."
+
+   {% endnote %}
+
+1. If you're adding a metadata restriction, configure the settings for the metadata restriction rule, then click **Add**. You can add multiple restrictions to the same ruleset.
+
+   For most requirements, such as "Must start with a matching pattern," the pattern you enter is interpreted literally, and wildcards are not supported. For example, the `*` character only represents the literal `*` character.
+   
+   For more complex patterns, you can select "Must match a given regex pattern" or "Must not match a given regex pattern," then use regular expression syntax to define the matching pattern. For more information, see "[Using regular expressions for commit metadata](#using-regular-expressions-for-commit-metadata)." 
+   
+   Anyone who views the rulesets for a repository will be able to see the description you provide.

data/reusables/repositories/rulesets-protections-step.md

@@ -0,0 +1 @@
+1. 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 "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets)."

data/reusables/repositories/rulesets-public-beta.md

@@ -0,0 +1,5 @@
+{% note %}
+
+**Note:** Rulesets are in public beta and subject to change.
+
+{% endnote %}

data/reusables/repositories/rulesets-sudo-mode.md

@@ -0,0 +1 @@
+You may be prompted to confirm access to your account before you can create, edit, or delete a ruleset. For more information, see "[AUTOTITLE](/authentication/keeping-your-account-and-data-secure/sudo-mode)."