зеркало из https://github.com/github/docs.git
Refactor protected branches content (#17277)
* Add new structure to index.md * Move all conceptual and troubleshooting content * Add more redirects * Update links * Reorganize "About" article * Tweak some conceptual content * Rename procedural article * Fix article title in index.md * Fix links * Add more redirects * Fix more links * Add redirects for "Managing..." and fix links * Consolidate procedural information * Remove duplicate redirect * Fix indentation * Add 💅 * Add header * Add editing and deleting * 💅 conceptual content * 💅 conceptual content * 💅 troubleshooting article * Clarify default behavior * 💅 gated feature clarification * Add 💅 * Add 💅 * update hardcoded links in tests * Fix gated feature reusable Co-Authored-By: Matt Pollard <mattpollard@users.noreply.github.com> * Step out of the way while Matt improves all of the legacy content Co-authored-by: Matt Pollard <mattpollard@users.noreply.github.com> * Tweak gated feature reusable Co-authored-by: Sarah Schneider <sarahs@github.com> Co-authored-by: Matt Pollard <mattpollard@users.noreply.github.com>
This commit is contained in:
Laura Coursen
GitHub
Родитель
27a6bbc8c2
Коммит
77ee3137ef
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 9.5 KiB |
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 9.6 KiB |
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 3.0 KiB |
|
|
@ -24,7 +24,7 @@ A CI server hosts code that runs CI tests such as code linters (which check styl
|
|||
|
||||
The [Checks API](/rest/reference/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/reference/repos#branches) can prevent people from merging pull requests prematurely. See "[Enabling required status checks](/articles/enabling-required-status-checks/)" 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/reference/repos#branches) can prevent people from merging pull requests prematurely. See "[About protected branches](/github/administering-a-repository/about-protected-branches#require-status-checks-before-merging)" for more details.
|
||||
|
||||
The Checks API sends the [`check_suite` webhook event](/webhooks/event-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/reference/checks#update-repository-preferences-for-check-suites) if you'd like. Here's how the default flow works:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,30 +0,0 @@
|
|||
---
|
||||
title: About branch restrictions
|
||||
intro: 'Branches within repositories that belong to organizations can be configured so that only certain users, teams, or apps can push to the branch.'
|
||||
product: '{% data reusables.gated-features.branch-restrictions %}'
|
||||
redirect_from:
|
||||
- /articles/about-branch-restrictions
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
When you enable branch restrictions, only users, teams, or apps that have been given permission can push to the protected branch. For more information, see "[Enabling branch restrictions](/articles/enabling-branch-restrictions)" and "[About protected branches](/articles/about-protected-branches)." You can view and edit the users, teams, or apps with push access to a protected branch in the protected branch's settings.
|
||||
|
||||
You can only give push access to a protected branch to users, teams, or installed {% data variables.product.prodname_github_apps %} with `write` access to a repository.
|
||||
|
||||
People and apps with admin permissions to a repository are always able to push to a protected branch.
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Note:** If "Include administrators" is selected, you've enabled required status checks on the branch, and if any status checks fail, any attempt to push changes to the protected branch will also fail, even for people and apps with admin permissions. For more information, see "[Enabling required status checks](/articles/enabling-required-status-checks)."
|
||||
|
||||
{% endtip %}
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[About protected branches](/articles/about-protected-branches)"
|
||||
- "[Configuring protected branches](/articles/configuring-protected-branches)"
|
||||
- "[About required status checks](/articles/about-required-status-checks)"
|
||||
- "[Enabling required status checks](/articles/enabling-required-status-checks)"
|
||||
|
|
@ -14,7 +14,7 @@ versions:
|
|||
{% data reusables.pull_requests.default_merge_option %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.19" %}
|
||||
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 "[Requiring a linear commit history](/github/administering-a-repository/requiring-a-linear-commit-history)."{% endif %}
|
||||
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 "[About protected branches](/github/administering-a-repository/about-protected-branches#require-linear-history)."{% endif %}
|
||||
|
||||
### Squashing your merge commits
|
||||
|
||||
|
|
|
|||
|
|
@ -1,38 +1,141 @@
|
|||
---
|
||||
title: About protected branches
|
||||
intro: 'Protected branches ensure that collaborators on your repository cannot make irrevocable changes to branches. Enabling protected branches also allows you to enable other optional checks and requirements, like required status checks and required reviews.'
|
||||
intro: 'You can protect important branches by setting branch protection rules, which define whether collaborators can delete or force push to the branch and set requirements for any pushes to the branch, such as passing status checks or a linear commit history.'
|
||||
product: '{% data reusables.gated-features.protected-branches %}'
|
||||
redirect_from:
|
||||
- /articles/about-protected-branches
|
||||
- /enterprise/admin/developer-workflow/about-protected-branches-and-required-status-checks
|
||||
- /articles/about-branch-restrictions
|
||||
- /github/administering-a-repository/about-branch-restrictions
|
||||
- /articles/about-required-status-checks
|
||||
- /github/administering-a-repository/about-required-status-checks
|
||||
- /articles/types-of-required-status-checks
|
||||
- /github/administering-a-repository/types-of-required-status-checks
|
||||
- /articles/about-required-commit-signing
|
||||
- /github/administering-a-repository/about-required-commit-signing
|
||||
- /articles/about-required-reviews-for-pull-requests
|
||||
- /github/administering-a-repository/about-required-reviews-for-pull-requests
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
### About protected branches
|
||||
### About branch protection rules
|
||||
|
||||
{% data reusables.pull_requests.about-protected-branches %} You can choose to enforce restrictions on how a pull request is merged into your repository.
|
||||
You can enforce certain workflows or requirements before a collaborator can push changes to a branch in your repository, including merging a pull request into the branch, by creating a branch protection rule.
|
||||
|
||||
Repository owners and people with admin permissions for a repository can enforce certain workflows or requirements, before a collaborator can merge a branch in your repository by creating protected branch rules.
|
||||
By default, each branch protection rule disables force pushes to the matching branches and prevents the matching branches from being deleted. You can optionally disable these restrictions and enable additional branch protection settings.
|
||||
|
||||
{% data reusables.repositories.branch-rules-example %} For more information, see "[Configuring protected branches](/articles/configuring-protected-branches/)."
|
||||
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.
|
||||
|
||||
{% data reusables.repositories.branch-rules-example %} For more information about branch name patterns, see "[Managing a branch protection rule](/github/administering-a-repository/managing-a-branch-protection-rule)."
|
||||
|
||||
{% data reusables.pull_requests.you-can-auto-merge %}
|
||||
|
||||
### Prioritization of protected branch rules
|
||||
### About branch protection settings
|
||||
|
||||
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.
|
||||
For each branch protection rule, you can choose to enable or disable the following settings.
|
||||
- [Require pull request reviews before merging](#require-pull-request-reviews-before-merging)
|
||||
- [Require status checks before merging](#require-status-checks-before-merging)
|
||||
- [Require signed commits](#require-signed-commits)
|
||||
- [Require linear history](#require-linear-history)
|
||||
- [Include administrators](#include-administrators)
|
||||
- [Restrict who can push to matching branches](#restrict-who-can-push-to-matching-branches)
|
||||
- [Allow force pushes](#allow-force-pushes)
|
||||
- [Allow deletions](#allow-deletions)
|
||||
|
||||
Protected branch rules that mention a special character, such as `*`, `?`, or `]`, are applied in the order they were created, so older rules with these characters have a higher priority.
|
||||
#### Require pull request reviews before merging
|
||||
|
||||
### Branch protection settings
|
||||
{% data reusables.pull_requests.required-reviews-for-prs-summary %}
|
||||
|
||||
When you create a branch protection rule in a repository, collaborators cannot force push to the protected branch or delete the branch{% if currentVersion == "free-pro-team@latest" %} by default{% endif %}. You can enable other branch protection settings. For information, see "[Defining the mergeability of pull requests](/github/administering-a-repository/defining-the-mergeability-of-pull-requests)."
|
||||
If you enable required reviews, collaborators can only push changes to a protected branch via a pull request that is approved by the required number of reviewers with write permissions.
|
||||
|
||||
### Further reading
|
||||
If a person with admin permissions 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.
|
||||
|
||||
- "[About required status checks](/articles/about-required-status-checks)"
|
||||
- "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)"
|
||||
- "[About required commit signing](/articles/about-required-commit-signing)"
|
||||
{% data reusables.repositories.review-policy-overlapping-commits %}
|
||||
|
||||
If a collaborator attempts to merge a pull request with pending or rejected reviews into the protected branch, the collaborator will receive an error message.
|
||||
|
||||
```shell
|
||||
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 "[About pull requests](/articles/about-pull-requests)."
|
||||
|
||||
Optionally, you can restrict the ability to dismiss pull request reviews to specific people or teams. For more information, see "[Dismissing a pull request review](/articles/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.
|
||||
|
||||
#### 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 "[About status checks](/github/collaborating-with-issues-and-pull-requests/about-status-checks)."
|
||||
|
||||
Before you can enable required status checks, you must configure the repository to use the status API. For more information, see "[Repositories](/rest/reference/repos#statuses)" in the REST 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.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Any person or integration with write permissions to a repository can set the state of any status check in the repository. {% data variables.product.company_short %} does not verify that the author of a check is authorized to create a check with a certain name or modify an existing status. Before merging a pull request, you should verify that the author of each status, listed in the merge box, is expected.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
You can set up required status checks to either be "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 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.|
|
||||
| **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 "[Troubleshooting required status checks](/github/administering-a-repository/troubleshooting-required-status-checks)."
|
||||
|
||||
#### Require signed commits
|
||||
|
||||
When you enable required commit signing on a branch, contributors {% if currentVersion == "free-pro-team@latest" %}and bots{% endif %} can only push commits that have been signed and verified to the branch. For more information, see "[About commit signature verification](/articles/about-commit-signature-verification)."
|
||||
|
||||
{% note %}
|
||||
|
||||
**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.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
You can always push local commits to the branch if the commits are signed and verified. {% if currentVersion == "free-pro-team@latest" %}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 {% if currentVersion == "free-pro-team@latest" %}squash and {% endif %}merge pull requests locally. For more information, see "[Checking out pull requests locally](/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally)."
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %} For more information about merge methods, see "[About merge methods on {% data variables.product.prodname_dotcom %}](/github/administering-a-repository/about-merge-methods-on-github)."{% endif %}
|
||||
|
||||
#### Require linear history
|
||||
|
||||
Enforcing a linear commit history prevents collaborators from pushing merge commits to the branch. This means that any pull requests merged into the protected branch 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 "[About pull request merges](/github/collaborating-with-issues-and-pull-requests/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 "[Configuring pull request merges](/github/administering-a-repository/configuring-pull-request-merges)."
|
||||
|
||||
#### Include administrators
|
||||
|
||||
By default, protected branch rules do not apply to people with admin permissions to a repository. You can enable this setting to include administrators in your protected branch rules.
|
||||
|
||||
#### Restrict who can push to matching branches
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
You can enable branch restrictions if your repository is owned by an organization using {% data variables.product.prodname_team %} or {% data variables.product.prodname_ghe_cloud %}.
|
||||
{% endif %}
|
||||
|
||||
When you enable branch restrictions, only users, teams, or apps that have been given permission can push to the protected branch. You can view and edit the users, teams, or apps with push access to a protected branch in the protected branch's settings.
|
||||
|
||||
You can only give push access to a protected branch to users, teams, or installed {% data variables.product.prodname_github_apps %} with write access to a repository. People and apps with admin permissions to a repository are always able to push to a protected branch.
|
||||
|
||||
#### Allow force pushes
|
||||
|
||||
By default, {% data variables.product.product_name %} blocks force pushes on all protected branches. When you enable force pushes to a protected branch, anyone with at least write permissions to the repository can force push to the branch, including those with admin permissions.
|
||||
|
||||
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.
|
||||
|
||||
{% if enterpriseServerVersions contains currentVersion or currentVersion == "github-ae@latest" %}You cannot enable force pushes for a protected branch if a site administrator has blocked force pushes to all branches in your repository. For more information, see "[Blocking force pushes to repositories owned by a user account or organization](/enterprise/{{ currentVersion }}/admin/developer-workflow/blocking-force-pushes-to-repositories-owned-by-a-user-account-or-organization)."
|
||||
|
||||
If a site administrator has blocked force pushes to the default branch only, you can still enable force pushes for any other protected branch.{% endif %}
|
||||
|
||||
#### Allow deletions
|
||||
|
||||
By default, you cannot delete a protected branch. When you enable deletion of a protected branch, anyone with at least write permissions to the repository can delete the branch.
|
||||
|
|
|
|||
|
|
@ -1,29 +0,0 @@
|
|||
---
|
||||
title: About required commit signing
|
||||
intro: Required commit signing ensures that collaborators can only push verified signed commits to a protected branch.
|
||||
product: '{% data reusables.gated-features.protected-branches %}'
|
||||
redirect_from:
|
||||
- /articles/about-required-commit-signing
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
If you've enforced branch protections in your repository, you can set up required commit signing. For more information, see "[Configuring protected branches](/articles/configuring-protected-branches/)."
|
||||
|
||||
When you enable required commit signing on a branch, contributors {% if currentVersion == "free-pro-team@latest" %}and bots{% endif %} can only push commits that have been signed and verified to the branch. For more information, see "[About commit signature verification](/articles/about-commit-signature-verification)."
|
||||
|
||||
You can always push local commits to the branch if the commits are signed and verified. {% if currentVersion == "free-pro-team@latest" %}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 {% if currentVersion == "free-pro-team@latest" %}squash and {% endif %}merge pull requests locally. For more information, see "[Checking out pull requests locally](/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally)."{% if currentVersion == "free-pro-team@latest" %} For more information about merge methods, see "[About merge methods on {% data variables.product.prodname_dotcom %}](/github/administering-a-repository/about-merge-methods-on-github)."{% endif %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Enabling required commit signing on a branch will make it more difficult to contribute. If a collaborator pushes an unsigned commit to a branch that has required commit signing enabled, they will need to rebase their commit to include a verified signature and force push the rewritten commit to the branch.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
Administrators of a repository can push local commits that have not been signed and verified, however you can require administrators to be subject to required commit signing. For more information, see "[Enabling required commit signing](/articles/enabling-required-commit-signing)."
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[About protected branches](/articles/about-protected-branches)"
|
||||
|
|
@ -1,36 +0,0 @@
|
|||
---
|
||||
title: About required reviews for pull requests
|
||||
intro: Required reviews ensure that pull requests have a specific number of approving reviews before collaborators can make changes to a protected branch.
|
||||
product: '{% data reusables.gated-features.protected-branches %}'
|
||||
redirect_from:
|
||||
- /articles/about-required-reviews-for-pull-requests
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
If you've enforced branch protections in your repository, you can set up required reviews. For more information about enforcing branch protections, see "[Configuring protected branches](/articles/configuring-protected-branches/)." For more information about setting up required reviews, see "[Enabling required reviews for pull requests](/articles/enabling-required-reviews-for-pull-requests)."
|
||||
|
||||
{% data reusables.pull_requests.required-reviews-for-prs-summary %}
|
||||
|
||||
If a person with *admin* permissions chooses the **Request changes** option in a review, then that person must approve the pull request before it can be merged. If a reviewer who requests changes on a pull request isn't available, anyone with *admin* or *write* permission for the repository can dismiss the blocking review. For more information, see "[Dismissing a pull request review](/articles/dismissing-a-pull-request-review)."
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Repository admins can restrict the ability to dismiss pull request reviews to specific people or teams. For more information, see "[Enabling required reviews for pull requests](/articles/enabling-required-reviews-for-pull-requests)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
If you push a code-modifying commit to the branch of an approved pull request, the approval may be dismissed if repository admins have set up stale review dismissals. For more information, see "[Enabling required reviews for pull requests](/articles/enabling-required-reviews-for-pull-requests)." This doesn't apply if you push non-code-modifying commits, like merging the base branch into your pull request's branch. For information about the base branch, see "[About pull requests](/articles/about-pull-requests)."
|
||||
|
||||
Unless required reviews have been set up to include repository admins, people with *admin* permissions can merge a pull request regardless of reviews from other admins.
|
||||
|
||||
{% data reusables.repositories.review-policy-overlapping-commits %}
|
||||
|
||||
You can't merge a pull request into a protected branch until someone with *write* or *admin* permissions approves it. If there are pending or rejected reviews, you'll receive an error message:
|
||||
|
||||
```shell
|
||||
remote: error: GH006: Protected branch update failed for refs/heads/main.
|
||||
remote: error: Changes have been requested.
|
||||
```
|
||||
|
|
@ -1,72 +0,0 @@
|
|||
---
|
||||
title: About required status checks
|
||||
intro: Required status checks ensure that all required CI tests are passing before collaborators can make changes to a protected branch.
|
||||
product: '{% data reusables.gated-features.protected-branches %}'
|
||||
redirect_from:
|
||||
- /articles/about-required-status-checks
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
### About required status checks
|
||||
|
||||
If you've enforced branch protections in your repository, you can set up required status checks. For more information, see "[Configuring protected branches](/articles/configuring-protected-branches/)" and "[Enabling required status checks](/articles/enabling-required-status-checks)." Required status checks can be checks or statuses. For more information, see "[About status checks](/github/administering-a-repository/enabling-required-status-checks)."
|
||||
|
||||
After enabling required status checks, all required status checks must pass before branches can be merged 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.
|
||||
|
||||
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Note:** Any person or integration with write permissions to a repository can set the state of any status check in the repository. {% data variables.product.product_name %} does not verify that the author of a check is authorized to create a check with a certain name or modify an existing status. Before merging a pull request, you should verify that the author of each status, listed in the merge box, is expected.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
Administrators of a repository can merge a protected branch even if required status checks have failed or are pending. You can require administrators to be subject to required status checks. For more information, see "[Enabling required status checks](/github/administering-a-repository/enabling-required-status-checks)."
|
||||
|
||||
|
||||
|
||||
Administrators can also merge a protected branch even if the branch is out of date with the base branch.
|
||||
|
||||
### Required status checks settings
|
||||
|
||||
You can set up either loose or strict status checks, depending on whether you want to require your branch to be up to date with the base branch before merging. For more information, see "[Types of required status checks](/github/administering-a-repository/types-of-required-status-checks)."
|
||||
|
||||
### Troubleshooting 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 "[Checks](/rest/reference/checks)."
|
||||
|
||||
Once you've set up required status checks, your branch must 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.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** You can also bring your branch up to date with the base branch using Git rebase. For more information, see "[About Git rebase](/github/using-git/about-git-rebase)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
|
||||
|
||||
You won't be able to push local changes to a protected branch until all required status checks pass. Instead, you'll receive an error message similar to the following:
|
||||
|
||||
```shell
|
||||
remote: error: GH006: Protected branch update failed for refs/heads/main.
|
||||
remote: error: Required status check "ci-build" is failing
|
||||
```
|
||||
{% note %}
|
||||
|
||||
**Note:** Pull requests that are up to date and pass required status checks can be merged locally and pushed to the protected branch. This can be done without status checks running on the merge commit itself.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.20" %}
|
||||
|
||||
Sometimes, the results of the status checks for the test merge commit and head commit will conflict. If the test merge commit has a status, it must pass. Otherwise, the status of the head commit must pass before you can merge the branch. For more information about test merge commits, see "[Pull Requests](/rest/reference/pulls#response-1)."
|
||||
|
||||
|
||||
{% endif %}
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[About status checks](/github/collaborating-with-issues-and-pull-requests/about-status-checks)"
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
---
|
||||
title: Configuring protected branches
|
||||
intro: 'If you''re a repository owner or have admin permissions in a repository, you can customize branch protections in the repository and enforce certain workflows, such as requiring more than one pull request review or requiring certain status checks to pass before allowing a pull request to merge.'
|
||||
product: '{% data reusables.gated-features.protected-branches %}'
|
||||
redirect_from:
|
||||
- /articles/configuring-protected-branches
|
||||
- /enterprise/admin/developer-workflow/configuring-protected-branches-and-required-status-checks
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
|
||||
{% data reusables.repositories.branch-rules-example %}
|
||||
|
||||
You can also set up automatic branch protection for all branches in your repository with the wildcard syntax `*`. Because {% data variables.product.prodname_dotcom %} 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 it 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).
|
||||
|
||||
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 the priority order and other settings for protected branch rules, see "[About protected branches](/github/administering-a-repository/about-protected-branches)."
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** To create a branch rule, the branch you specify doesn't have to exist yet in the repository.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.repository-branches %}
|
||||
{% data reusables.repositories.add-branch-protection-rules %}
|
||||
6. Optionally, you can configure specific branch rule settings.
|
||||
|
||||
7. To confirm your branch protection rule, click **Create** or **Save changes.**
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[About protected branches](/github/administering-a-repository/about-protected-branches)"
|
||||
- "[About required status checks](/github/administering-a-repository/about-required-status-checks)"
|
||||
- "[Enabling required status checks](/github/administering-a-repository/enabling-required-status-checks)"
|
||||
- "[About branch restrictions](/github/administering-a-repository/about-branch-restrictions)"
|
||||
- "[Enabling branch restrictions](/github/administering-a-repository/enabling-branch-restrictions)"
|
||||
- "[About required commit signing](/github/administering-a-repository/about-required-commit-signing)"
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
---
|
||||
title: Enabling branch restrictions
|
||||
intro: 'You can enforce branch restrictions so that only certain users, teams, or apps can push to a protected branch in repositories owned by your organization.'
|
||||
product: '{% data reusables.gated-features.branch-restrictions %}'
|
||||
redirect_from:
|
||||
- /articles/enabling-branch-restrictions
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
Anyone with admin permissions to an organization-owned repository can enable branch restrictions.
|
||||
|
||||
{% data reusables.repositories.protected-branches-options %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.repository-branches %}
|
||||
{% data reusables.repositories.add-branch-protection-rules %}
|
||||
{% data reusables.repositories.include-administrators %}
|
||||
6. Under "Protect matching branches", select **Restrict who can push to matching branches**.
|
||||
|
||||
8. Search for and select the people, teams, or apps who will have permission to push to the protected branch.
|
||||
|
||||
9. Click **Create**.
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[About protected branches](/github/administering-a-repository/about-protected-branches)"
|
||||
- "[Configuring protected branches](/github/administering-a-repository/configuring-protected-branches)"
|
||||
- "[About required status checks](/github/administering-a-repository/about-required-status-checks)"
|
||||
- "[Enabling required status checks](/github/administering-a-repository/enabling-required-status-checks)"
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
---
|
||||
title: Enabling deletion of a protected branch
|
||||
intro: You can allow anyone with write access for a repository to delete a protected branch.
|
||||
product: '{% data reusables.gated-features.protected-branches %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.20'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
Anyone with admin permissions to a repository can enable branch deletions.
|
||||
|
||||
By default, you cannot delete a protected branch. When you enable deletion to a protected branch, anyone with at least write permissions to the repository can delete the branch, including those with admin permissions.
|
||||
|
||||
{% data reusables.repositories.protected-branches-options %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.repository-branches %}
|
||||
{% data reusables.repositories.add-branch-protection-rules %}
|
||||
6. Under "Rules applied to everyone including administrators", select **Allow deletions**.
|
||||
|
||||
7. Click **Create**.
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
---
|
||||
title: Enabling force pushes to a protected branch
|
||||
intro: You can allow force pushes to a protected branch.
|
||||
product: '{% data reusables.gated-features.protected-branches %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.20'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
Anyone with admin permissions to a repository can enable force pushes.
|
||||
|
||||
### About force pushes to protected branches
|
||||
|
||||
By default, force pushes are blocked on all protected branches. When you enable force pushes to a protected branch, anyone with at least write permissions to the repository can force push to the branch, including those with admin permissions.
|
||||
|
||||
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.
|
||||
|
||||
{% if enterpriseServerVersions contains currentVersion or currentVersion == "github-ae@latest" %}You cannot enable force pushes for a protected branch if a site administrator has blocked force pushes to all branches in your repository. For more information, see "[Blocking force pushes to repositories owned by a user account or organization](/enterprise/{{ currentVersion }}/admin/developer-workflow/blocking-force-pushes-to-repositories-owned-by-a-user-account-or-organization)."
|
||||
|
||||
If a site administrator has blocked force pushes to the default branch only, you can still enable force pushes for any other protected branch.{% endif %}
|
||||
|
||||
{% data reusables.repositories.protected-branches-options %}
|
||||
|
||||
### Enabling force pushes
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.repository-branches %}
|
||||
{% data reusables.repositories.add-branch-protection-rules %}
|
||||
6. Under "Rules applied to everyone including administrators", select **Allow force pushes**.
|
||||
|
||||
7. Click **Create**.
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
---
|
||||
title: Enabling required commit signing
|
||||
intro: Repository administrators can enforce required commit signing on a branch to block all commits that are not signed and verified.
|
||||
product: '{% data reusables.gated-features.protected-branches %}'
|
||||
redirect_from:
|
||||
- /articles/enabling-required-commit-signing
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
Before enabling required commit signing on a branch, you must first set the branch up as a protected branch. For more information, see "[Configuring protected branches](/github/administering-a-repository/configuring-protected-branches)."
|
||||
|
||||
{% data reusables.repositories.protected-branches-options %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.repository-branches %}
|
||||
{% data reusables.repositories.add-branch-protection-rules %}
|
||||
5. Select **Require signed commits**.
|
||||
|
||||
6. Optionally, select **Include administrators**. This enforces the required signed commits on the repository administrators.
|
||||
|
||||
7. Click **Create**.
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
---
|
||||
title: Enabling required reviews for pull requests
|
||||
intro: Repository administrators can enforce required reviews so that pull requests must have a specific number of approving reviews before they are merged.
|
||||
product: '{% data reusables.gated-features.protected-branches %}'
|
||||
redirect_from:
|
||||
- /articles/enabling-required-reviews-for-pull-requests
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
Before enabling required reviews on a branch, you must first set the branch up as a protected branch. For more information, see "[Configuring protected branches](/github/administering-a-repository/configuring-protected-branches)."
|
||||
|
||||
{% data reusables.repositories.protected-branches-options %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.repository-branches %}
|
||||
{% data reusables.repositories.add-branch-protection-rules %}
|
||||
5. Select **Require pull request reviews before merging**.
|
||||
|
||||
6. In the Required approving reviews drop-down menu, select the number of approving reviews you'd like to require on the branch.
|
||||
|
||||
7. Optionally, select **Dismiss stale pull request approvals when new commits are pushed**. This dismisses a pull request approval review when a code-modifying commit is pushed to the branch.
|
||||
|
||||
8. Optionally, select **Require review from Code Owners** to require review from a code owner when the pull request affects code that has a designated owner. For more information, see "[About code owners](/github/creating-cloning-and-archiving-repositories/about-code-owners)."
|
||||
|
||||
9. Optionally, if the repository is part of an organization, select **Restrict who can dismiss pull request reviews** to search for and select the people or teams who can dismiss pull request reviews. For more information, see "[Dismissing a pull request review](/github/collaborating-with-issues-and-pull-requests/dismissing-a-pull-request-review)." This option is not available for personal repositories.
|
||||
|
||||
{% data reusables.repositories.include-administrators %}
|
||||
11. Click **Create**.
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[About required reviews for pull requests](/github/administering-a-repository/about-required-reviews-for-pull-requests)"
|
||||
- "[About protected branches](/github/administering-a-repository/about-protected-branches)"
|
||||
- "[About required status checks](/github/administering-a-repository/about-required-status-checks)"
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
---
|
||||
title: Enabling required status checks
|
||||
intro: Repository administrators can enforce required status checks before a branch is merged in a pull request or before commits on a local branch can be pushed to the protected remote branch.
|
||||
product: '{% data reusables.gated-features.protected-branches %}'
|
||||
redirect_from:
|
||||
- /articles/enabling-required-status-checks
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
{% data reusables.repositories.protected-branches-options %}
|
||||
|
||||
Before you can enable required status checks, you must configure the repository to use the status API. For more information, see "[Building a CI Server](/guides/building-a-ci-server/)."
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.repository-branches %}
|
||||
{% data reusables.repositories.add-branch-protection-rules %}
|
||||
6. Under "Protect matching branches", select **Require status checks to pass before merging**.
|
||||
|
||||
7. Optionally, select **Require branches to be up to date before merging**. If selected, this ensures that the branch is tested with the latest code on the base branch.
|
||||
|
||||
7. From the list of available status checks, select the checks you want to require.
|
||||
|
||||
{% data reusables.repositories.include-administrators %}
|
||||
9. Click **Create**.
|
||||
|
||||
{% data reusables.repositories.required-status-merge-tip %}
|
||||
|
|
@ -44,19 +44,8 @@ versions:
|
|||
{% link_in_list /managing-the-automatic-deletion-of-branches %}
|
||||
{% topic_link_in_list /defining-the-mergeability-of-pull-requests %}
|
||||
{% link_in_list /about-protected-branches %}
|
||||
{% link_in_list /configuring-protected-branches %}
|
||||
{% link_in_list /about-required-status-checks %}
|
||||
{% link_in_list /types-of-required-status-checks %}
|
||||
{% link_in_list /enabling-required-status-checks %}
|
||||
{% link_in_list /about-branch-restrictions %}
|
||||
{% link_in_list /enabling-branch-restrictions %}
|
||||
{% link_in_list /about-required-reviews-for-pull-requests %}
|
||||
{% link_in_list /enabling-required-reviews-for-pull-requests %}
|
||||
{% link_in_list /about-required-commit-signing %}
|
||||
{% link_in_list /enabling-required-commit-signing %}
|
||||
{% link_in_list /requiring-a-linear-commit-history %}
|
||||
{% link_in_list /enabling-force-pushes-to-a-protected-branch %}
|
||||
{% link_in_list /enabling-deletion-of-a-protected-branch %}
|
||||
{% link_in_list /managing-a-branch-protection-rule %}
|
||||
{% link_in_list /troubleshooting-required-status-checks %}
|
||||
{% topic_link_in_list /releasing-projects-on-github %}
|
||||
{% link_in_list /about-releases %}
|
||||
{% link_in_list /managing-releases-in-a-repository %}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,100 @@
|
|||
---
|
||||
title: Managing a branch protection rule
|
||||
intro: 'You can create a branch protection rule to enforce certain workflows for one or more branches, such as requiring an approving review or passing status checks for all pull requests merged into the protected branch.'
|
||||
product: '{% data reusables.gated-features.protected-branches %}'
|
||||
redirect_from:
|
||||
- /articles/configuring-protected-branches
|
||||
- /enterprise/admin/developer-workflow/configuring-protected-branches-and-required-status-checks
|
||||
- /articles/enabling-required-status-checks
|
||||
- /github/administering-a-repository/enabling-required-status-checks
|
||||
- /articles/enabling-branch-restrictions
|
||||
- /github/administering-a-repository/enabling-branch-restrictions
|
||||
- /articles/enabling-required-reviews-for-pull-requests
|
||||
- /github/administering-a-repository/enabling-required-reviews-for-pull-requests
|
||||
- /articles/enabling-required-commit-signing
|
||||
- /github/administering-a-repository/enabling-required-commit-signing
|
||||
- /github/administering-a-repository/requiring-a-linear-commit-history
|
||||
- /github/administering-a-repository/enabling-force-pushes-to-a-protected-branch
|
||||
- /github/administering-a-repository/enabling-deletion-of-a-protected-branch
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
permissions: People with admin permissions to a repository can manage branch protection rules.
|
||||
---
|
||||
|
||||
### About branch protection rules
|
||||
|
||||
{% 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).
|
||||
|
||||
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.
|
||||
|
||||
Protected branch rules that mention a special character, such as `*`, `?`, or `]`, are applied in the order they were created, so older rules with these characters have a higher priority.
|
||||
|
||||
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 each of the available branch protection settings, see "[About protected branches](/github/administering-a-repository/about-protected-branches)."
|
||||
|
||||
### Creating a branch protection rule
|
||||
|
||||
When you create a branch rule, the branch you specify doesn't have to exist yet in the repository.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.repository-branches %}
|
||||
{% data reusables.repositories.add-branch-protection-rules %}
|
||||
1. Optionally, enable required pull request reviews.
|
||||
- Under "Protect matching branches", select **Require pull request reviews before merging**.
|
||||
|
||||
- Click the **Required approving reviews** drop-down menu, then select the number of approving reviews you'd like to require on the branch.
|
||||
|
||||
- Optionally, to dismiss a pull request approval review when a code-modifying commit is pushed to the branch, select **Dismiss stale pull request approvals when new commits are pushed**.
|
||||
|
||||
- Optionally, to require review from a code owner when the pull request affects code that has a designated owner, select **Require review from Code Owners**. For more information, see "[About code owners](/github/creating-cloning-and-archiving-repositories/about-code-owners)."
|
||||
|
||||
- Optionally, if the repository is part of an organization, select **Restrict who can dismiss pull request reviews**. Then, search for and select the people or teams who are allowed to dismiss pull request reviews. For more information, see "[Dismissing a pull request review](/github/collaborating-with-issues-and-pull-requests/dismissing-a-pull-request-review)."
|
||||
|
||||
1. Optionally, enable required status checks.
|
||||
- Select **Require status checks to pass before merging**.
|
||||
|
||||
- Optionally, to ensure that pull requests are tested with the latest code on the protected branch, select **Require branches to be up to date before merging**.
|
||||
|
||||
- From the list of available status checks, select the checks you want to require.
|
||||
|
||||
1. Optionally, select **Require signed commits**.
|
||||
|
||||
1. Optionally, select **Require linear history**.
|
||||
|
||||
1. Optionally, select **Include administrators**.
|
||||
|
||||
1. Optionally,{% if currentVersion == "free-pro-team@latest" %} if your repository is owned by an organization using {% data variables.product.prodname_team %} or {% data variables.product.prodname_ghe_cloud %},{% endif %} enable branch restrictions.
|
||||
- Select **Restrict who can push to matching branches**.
|
||||
|
||||
- Search for and select the people, teams, or apps who will have permission to push to the protected branch.
|
||||
|
||||
1. Optionally, under "Rules applied to everyone including administrators", select **Allow force pushes**.
|
||||
|
||||
1. Optionally, select **Allow deletions**.
|
||||
|
||||
1. Click **Create**.
|
||||
|
||||
### Editing a branch protection rule
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.repository-branches %}
|
||||
1. To the right of the branch protection rule you want to edit, click **Edit**.
|
||||
|
||||
1. Make your desired changes to the branch protection rule.
|
||||
1. Click **Save changes**.
|
||||
|
||||
|
||||
### Deleting a branch protection rule
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.repository-branches %}
|
||||
1. To the right of the branch protection rule you want to delete, click **Delete**.
|
||||
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
---
|
||||
title: Requiring a linear commit history
|
||||
intro: You can require a linear commit history to block all merge commits from a protected branch.
|
||||
product: '{% data reusables.gated-features.protected-branches %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.20'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
Anyone with admin permissions to a repository can require a linear commit history.
|
||||
|
||||
### About enforcement of linear commit history
|
||||
|
||||
Enforcing a linear commit history prevents merge commits from being pushed to the protected branch. This means that any pull requests merged into the protected branch must use a squash merge or a rebase merge. A strictly linear commit history can help teams backtrack changes more efficiently. For more information about merge methods, see "[About pull request merges](/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges)."
|
||||
|
||||
{% data reusables.repositories.protected-branches-options %}
|
||||
|
||||
Before you can require a linear commit history, your repository must allow squash merging or rebase merging. For more information, see "[Configuring pull request merges](/github/administering-a-repository/configuring-pull-request-merges)."
|
||||
|
||||
|
||||
### Enforcing a linear commit history
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.repository-branches %}
|
||||
{% data reusables.repositories.add-branch-protection-rules %}
|
||||
6. Under "Protect matching branches", select **Require linear history**.
|
||||
|
||||
{% data reusables.repositories.include-administrators %}
|
||||
7. Click **Create**.
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
---
|
||||
title: Troubleshooting required status checks
|
||||
intro: 'You can check for common errors and resolve issues with required status checks.'
|
||||
product: '{% data reusables.gated-features.protected-branches %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
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 "[Checks](/rest/reference/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 "[About protected branches](/github/administering-a-repository/about-protected-branches#require-status-checks-before-merging)."
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** You can also bring your branch up to date with the base branch using Git rebase. For more information, see "[About Git rebase](/github/using-git/about-git-rebase)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
You won't be able to push local changes to a protected branch until all required status checks pass. Instead, you'll receive an error message similar to the following.
|
||||
|
||||
```shell
|
||||
remote: error: GH006: Protected branch update failed for refs/heads/main.
|
||||
remote: error: Required status check "ci-build" is failing
|
||||
```
|
||||
{% note %}
|
||||
|
||||
**Note:** Pull requests that are up-to-date and pass required status checks can be merged locally and pushed to the protected branch. This can be done without status checks running on the merge commit itself.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.20" %}
|
||||
|
||||
Sometimes, the results of the status checks for the test merge commit and head commit will conflict. If the test merge commit has a status, the test merge commit must pass. Otherwise, the status of the head commit must pass before you can merge the branch. For more information about test merge commits, see "[Pulls](/rest/reference/pulls#get-a-pull-request)."
|
||||
|
||||
|
||||
{% endif %}
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
---
|
||||
title: Types of required status checks
|
||||
intro: You can set up required status checks to either be "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.
|
||||
product: '{% data reusables.gated-features.protected-branches %}'
|
||||
redirect_from:
|
||||
- /articles/types-of-required-status-checks
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
| 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.|
|
||||
| **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.
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[About required status checks](/articles/about-required-status-checks)"
|
||||
- "[Enabling required status checks](/articles/enabling-required-status-checks)"
|
||||
|
|
@ -19,7 +19,7 @@ You can sign commits and tags locally, so other people can verify that your work
|
|||
|
||||
If a commit or tag has a signature that cannot be verified, {% data variables.product.product_name %} marks the commit or tag as unverified.
|
||||
|
||||
Repository administrators can enforce required commit signing on a branch to block all commits that are not signed and verified. For more information, see "[About required commit signing](/articles/about-required-commit-signing)."
|
||||
Repository administrators can enforce required commit signing on a branch to block all commits that are not signed and verified. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-signed-commits)."
|
||||
|
||||
You can check the verification status of your signed commits or tags on {% data variables.product.product_name %} and view why your commit signatures might be unverified. For more information, see "[Checking your commit and tag signature verification status](/articles/checking-your-commit-and-tag-signature-verification-status)."
|
||||
|
||||
|
|
|
|||
|
|
@ -74,7 +74,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 "[About status checks](/articles/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 "[Merging a pull request](/articles/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 "[About code owners](/articles/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 "[About commit signature verification](/articles/about-commit-signature-verification)" and "[About required commit signing](/articles/about-required-commit-signing)."{% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.21" %}
|
||||
- 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 "[About commit signature verification](/articles/about-commit-signature-verification)" and "[About protected branches](/github/administering-a-repository/about-protected-branches#require-signed-commits)."{% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.21" %}
|
||||
- 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 "[Resolving a merge conflict on {% data variables.product.prodname_dotcom %}](/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github)."{% endif %}
|
||||
|
||||
### Further reading
|
||||
|
|
|
|||
|
|
@ -44,9 +44,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 "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)."
|
||||
{% data reusables.pull_requests.required-reviews-for-prs-summary %} For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)."
|
||||
|
||||
{% tip %}
|
||||
|
||||
|
|
@ -57,6 +55,5 @@ For more information, see "[About required reviews for pull requests](/articles/
|
|||
### Further reading
|
||||
|
||||
- "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)"
|
||||
- "[Enabling required reviews for pull requests](/articles/enabling-required-reviews-for-pull-requests)"
|
||||
- "[Viewing a pull request review](/articles/viewing-a-pull-request-review)"
|
||||
- "[Setting guidelines for repository contributors](/articles/setting-guidelines-for-repository-contributors)"
|
||||
|
|
|
|||
|
|
@ -9,9 +9,9 @@ versions:
|
|||
github-ae: '*'
|
||||
---
|
||||
|
||||
For more information about required reviews, see "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)."
|
||||
For more information about required reviews, see "[About protected branches](/github/administering-a-repository/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 "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)" and "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)."
|
||||
You can comment on a pull request, approve the changes, or request improvements before approving. For more information, see "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)."
|
||||
|
||||
{% data reusables.search.requested_reviews_search %}
|
||||
|
||||
|
|
@ -34,6 +34,5 @@ You can comment on a pull request, approve the changes, or request improvements
|
|||
|
||||
### Further reading
|
||||
|
||||
- "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)"
|
||||
- "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)"
|
||||
- "[Commenting on a pull request](/articles/commenting-on-a-pull-request)"
|
||||
|
|
|
|||
|
|
@ -13,7 +13,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](/articles/about-branch-restrictions) that will prevent you from committing
|
||||
- don't have [branch restrictions](/github/administering-a-repository/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 "[Allowing changes to a pull request branch created from a fork](/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)."
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Dismissing a pull request review
|
||||
intro: 'If your repository [requires reviews](/articles/about-required-reviews-for-pull-requests), you can dismiss pull request reviews that are no longer valid or are unable to be approved by the reviewer.'
|
||||
intro: 'If your repository requires reviews, you can dismiss pull request reviews that are no longer valid or are unable to be approved by the reviewer.'
|
||||
redirect_from:
|
||||
- /articles/dismissing-a-pull-request-review
|
||||
versions:
|
||||
|
|
@ -26,4 +26,4 @@ This changes the status of the review to a review comment. When you dismiss a re
|
|||
|
||||
- "[About pull request reviews](/articles/about-pull-request-reviews)"
|
||||
- "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)"
|
||||
- "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)"
|
||||
- "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)"
|
||||
|
|
@ -12,7 +12,7 @@ versions:
|
|||
|
||||
### 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. {% data reusables.pull_requests.about-protected-branches %} 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 "[About protected branches](/github/administering-a-repository/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. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches)."
|
||||
|
||||
{% data reusables.pull_requests.you-can-auto-merge %}
|
||||
|
||||
|
|
|
|||
|
|
@ -70,5 +70,5 @@ After you've finished reviewing all the files you want in the pull request, subm
|
|||
|
||||
### Further reading
|
||||
|
||||
- "[About required reviews for pull requests](/github/administering-a-repository/about-required-reviews-for-pull-requests)"
|
||||
- "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)"
|
||||
- "[Filtering pull requests by review status](/github/managing-your-work-on-github/filtering-pull-requests-by-review-status)"
|
||||
|
|
|
|||
|
|
@ -19,7 +19,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 "[About pull requests](/github/collaborating-with-issues-and-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 "[Changing the stage of a pull request](/github/collaborating-with-issues-and-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 "[Enabling required reviews for pull requests](/github/administering-a-repository/enabling-required-reviews-for-pull-requests)."
|
||||
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 "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)."
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.19" %}If a team has enabled code review assignments, the individual approvals won't satisfy the requirement for code owner approval in a protected branch. For more information, see "[Managing code review assignment for your team](/github/setting-up-and-managing-organizations-and-teams/managing-code-review-assignment-for-your-team)."{% endif %}
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ versions:
|
|||
|
||||
In repositories where {% data variables.product.prodname_code_scanning %} is configured as a pull request check, {% data variables.product.prodname_code_scanning %} checks the code in the pull request. By default, this is limited to pull requests that target the default branch, but you can change this configuration within {% data variables.product.prodname_actions %} or in a third-party CI/CD system. If merging the changes would introduce new {% data variables.product.prodname_code_scanning %} alerts to the target branch, these are reported as check results in the pull request. The alerts are also shown as annotations in the **Files changed** tab of the pull request. If you have write permission for the repository, you can see any existing {% data variables.product.prodname_code_scanning %} alerts on the **Security** tab. For information about repository alerts, see "[Managing {% data variables.product.prodname_code_scanning %} alerts for your repository](/github/finding-security-vulnerabilities-and-errors-in-your-code/managing-code-scanning-alerts-for-your-repository)."
|
||||
|
||||
If {% data variables.product.prodname_code_scanning %} has any results with a severity of `error`, the check fails and the error is reported in the check results. If all the results found by {% data variables.product.prodname_code_scanning %} have lower severities, the alerts are treated as warnings or notices and the check succeeds. If your pull request targets a protected branch that has been enabled for {% data variables.product.prodname_code_scanning %}, and the repository owner has configured required status checks, then you must either fix or {% if currentVersion == "enterprise-server@2.22" %}close{% else %}dismiss{% endif %} all error alerts before the pull request can be merged. For more information, see "[About required status checks](/github/administering-a-repository/about-required-status-checks)."
|
||||
If {% data variables.product.prodname_code_scanning %} has any results with a severity of `error`, the check fails and the error is reported in the check results. If all the results found by {% data variables.product.prodname_code_scanning %} have lower severities, the alerts are treated as warnings or notices and the check succeeds. If your pull request targets a protected branch that has been enabled for {% data variables.product.prodname_code_scanning %}, and the repository owner has configured required status checks, then you must either fix or {% if currentVersion == "enterprise-server@2.22" %}close{% else %}dismiss{% endif %} all error alerts before the pull request can be merged. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-status-checks-before-merging)."
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ versions:
|
|||
|
||||
You can filter a repository's list of pull requests to find:
|
||||
- Pull requests that haven't been [reviewed](/articles/about-pull-request-reviews) yet
|
||||
- Pull requests that [require a review](/articles/about-required-reviews-for-pull-requests) before they can be merged
|
||||
- Pull requests that [require a review](/github/administering-a-repository/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
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ For issues, you can also use search to:
|
|||
For pull requests, you can also use search to:
|
||||
- Filter [draft](/articles/about-pull-requests#draft-pull-requests) pull requests: `is:draft`
|
||||
- Filter pull requests that haven't been [reviewed](/articles/about-pull-request-reviews) yet: `state:open type:pr review:none`
|
||||
- Filter pull requests that [require a review](/articles/about-required-reviews-for-pull-requests) before they can be merged: `state:open type:pr review:required`
|
||||
- Filter pull requests that [require a review](/github/administering-a-repository/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](/articles/about-pull-request-reviews/): `state:open type:pr reviewed-by:octocat`
|
||||
|
|
|
|||
|
|
@ -1,3 +0,0 @@
|
|||
{% data reusables.gated-features.protected-branches %}
|
||||
<br>
|
||||
Branch restriction is a type of branch protection that's available for public and private repositories owned by organizations in {% data variables.product.prodname_team %}, {% data variables.product.prodname_ghe_cloud %},{% if currentVersion == "github-ae@latest" %} {% data variables.product.prodname_ghe_managed %},{% endif %} and {% data variables.product.prodname_ghe_server %}. {% if currentVersion == "free-pro-team@latest" %}{% data reusables.gated-features.more-info %}{% endif %}
|
||||
|
|
@ -1 +1 @@
|
|||
Protected branches 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 %}, {% data variables.product.prodname_ghe_cloud %},{% if currentVersion == "github-ae@latest" %} {% data variables.product.prodname_ghe_managed %},{% endif %} and {% data variables.product.prodname_ghe_server %}. {% if currentVersion == "free-pro-team@latest" %}{% data reusables.gated-features.more-info %}{% endif %}
|
||||
{% if currentVersion == "github-ae@latest" %}Protected branches are available in internal and private repositories with {% data variables.product.prodname_ghe_managed %}, {% else%}Protected branches are available {% endif %}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 %}, {% data variables.product.prodname_ghe_cloud %}, and {% data variables.product.prodname_ghe_server %}. {% if currentVersion == "free-pro-team@latest" %}{% data reusables.gated-features.more-info %}{% endif %}
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
By default, any pull request can be merged at any time, unless the head branch is in conflict with the base branch.
|
||||
|
|
@ -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 "[About required status checks](/articles/about-required-status-checks)."
|
||||
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 "[About protected branches](/github/administering-a-repository/about-protected-branches#require-status-checks-before-merging)."
|
||||
|
|
|
|||
|
|
@ -1,3 +1 @@
|
|||
Repository administrators can require that all pull requests receive a specific number of approving reviews from people with *write* or *admin* permissions in the repository or from a designated code owner before they're merged into a protected branch. For more information, see "[About protected branches](/articles/about-protected-branches)."
|
||||
|
||||
When required reviews are enabled, anyone with access to the repository can approve changes in a pull request. However, you won't be able to merge your pull request until the required number of reviewers with *write* or *admin* permissions in the repository approve your pull request's changes in their review. For more information about repository permission levels, see "[Repository permission levels for an organization](/articles/repository-permission-levels-for-an-organization/)." If review is required from a designated code owner and the pull request affects code that has a designated owner, approval from that owner is required.
|
||||
Repository administrators can require that all pull requests receive a specific number of approving reviews before someone merges the pull request into a protected branch. You can require approving reviews from people with write permissions in the repository or from a designated code owner.
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
You can create a branch rule in a repository for a specific branch, all branches, or any branch that matches a naming pattern specified with the fnmatch syntax. For example, to require any branch containing the word `release` to have at least two pull request reviews before merging, you can create a branch rule for `*release*`.
|
||||
You can create a branch protection rule in a repository for a specific branch, all branches, or any branch that matches a name pattern you specify with `fnmatch` syntax. For example, to protect any branches containing the word `release`, you can create a branch rule for `*release*`.
|
||||
|
|
|
|||
|
|
@ -1,2 +0,0 @@
|
|||
1. Optionally, select **Include administrators**. This enforces all configured restrictions for repository administrators.
|
||||
|
||||
|
|
@ -1 +0,0 @@
|
|||
You can automatically enforce protected branch settings for some or all branches in your repository. For more information, see "[Configuring protected branches](/github/administering-a-repository/configuring-protected-branches)."
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
{% tip %}
|
||||
|
||||
**Tip:** To successfully merge a pull request into a base branch that has required status checks enabled, the pull request's head branch must be up-to-date with the base branch.
|
||||
|
||||
{% endtip %}
|
||||
|
|
@ -1 +1 @@
|
|||
After all required reviewers have approved a pull request, you won't be able to merge it if there are other open pull requests with pending or rejected reviews and those pull requests have a head branch pointing to the same commit. Someone with *write* or *admin* permissions will need to approve or dismiss the blocking review on the other pull requests before you can merge.
|
||||
Even after all required reviewers have approved a pull request, collaborators cannot merge the pull request if there are other open pull requests that have a head branch pointing to the same commit with pending or rejected reviews. Someone with write permissions must approve or dismiss the blocking review on the other pull requests first.
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.19" or currentVersion == "github-ae@latest" %}If there is a protected branch rule in your repository that requires a linear commit history, you must allow squash merging, rebase merging, or both. For more information, see "[Requiring a linear commit history](/github/administering-a-repository/requiring-a-linear-commit-history)."{% endif %}
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.19" or currentVersion == "github-ae@latest" %}If there is a protected branch rule in your repository that requires a linear commit history, you must allow squash merging, rebase merging, or both. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)."{% endif %}
|
||||
|
|
|
|||
|
|
@ -21,8 +21,8 @@ describe('header', () => {
|
|||
|
||||
describe('language links', () => {
|
||||
test('lead to the same page in a different language', async () => {
|
||||
const $ = await getDOM('/en/github/administering-a-repository/enabling-required-status-checks')
|
||||
expect($(`#languages-selector a[href="/ja/${nonEnterpriseDefaultVersion}/github/administering-a-repository/enabling-required-status-checks"]`).length).toBe(1)
|
||||
const $ = await getDOM('/github/administering-a-repository/managing-a-branch-protection-rule')
|
||||
expect($(`#languages-selector a[href="/ja/${nonEnterpriseDefaultVersion}/github/administering-a-repository/managing-a-branch-protection-rule"]`).length).toBe(1)
|
||||
})
|
||||
|
||||
test('display the native name and the English name for each translated language', async () => {
|
||||
|
|
@ -80,7 +80,7 @@ describe('header', () => {
|
|||
})
|
||||
|
||||
test('point to homepages in the current page\'s language', async () => {
|
||||
const $ = await getDOM('/ja/articles/enabling-required-status-checks')
|
||||
const $ = await getDOM('/ja/github/administering-a-repository/defining-the-mergeability-of-pull-requests')
|
||||
|
||||
expect($(`#homepages a.active[href="/ja/${nonEnterpriseDefaultVersion}/github"]`).length).toBe(1)
|
||||
expect($(`#homepages a[href="/ja/enterprise-server@${latest}/admin"]`).length).toBe(1)
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче