зеркало из https://github.com/github/docs.git
[Improvement]: Improve documentation for "last pusher" branch protection (#36624)
Co-authored-by: Laura Coursen <lecoursen@github.com>
This commit is contained in:
Sophie
GitHub
Родитель
6ead7d41fa
Коммит
e56e5a0975
|
|
@ -97,7 +97,7 @@ Optionally, you can restrict the ability to dismiss pull request reviews to spec
|
|||
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 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.
|
||||
Optionally, you can require that the most recent reviewable push must be approved by someone other than the person who pushed it. 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 %}
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ When you create a branch rule, the branch you specify doesn't have to exist yet
|
|||
- Optionally, to allow specific actors to push code to the branch without creating pull requests when they're required, select **Allow specified actors to bypass required pull requests**. Then, search for and select the actors who should be allowed to skip creating a pull request.
|
||||
- Optionally, if the repository is part of an organization, select **Restrict who can dismiss pull request reviews**. Then, in the search field, search for and select the actors who are allowed to dismiss pull request reviews. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/dismissing-a-pull-request-review)."
|
||||
{% ifversion last-pusher-require-approval %}
|
||||
- Optionally, to require someone other than the last person to push to a branch to approve a pull request prior to merging, select **Require approval from someone other than the last pusher**. 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)."
|
||||
- Optionally, to require someone other than the last person to push to a branch to approve a pull request prior to merging, select **Require approval of the most recent reviewable push**. 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)."
|
||||
{% endif %}
|
||||
1. Optionally, enable required status checks. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks)."
|
||||
- Select **Require status checks to pass before merging**.
|
||||
|
|
|
|||
|
|
@ -3,5 +3,4 @@
|
|||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>=3.8'
|
||||
ghae: '>=3.8'
|
||||
ghes: '>=3.10'
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ sections:
|
|||
- |
|
||||
To establish or comply with internal policies, site administrators can use the Management Console to configure an instance's policy for retention of data related to checks, including checks data generated by GitHub Actions and the Statuses API. Administrators can enable or disable retention, set a custom retention threshold, or set a custom hard-delete threshold.
|
||||
For more information, see "[Configuring applications](/admin/configuration/configuring-your-enterprise/configuring-applications)" [Updated: 2023-03-02]
|
||||
|
||||
|
||||
|
||||
# https://github.com/github/releases/issues/2814
|
||||
- |
|
||||
|
|
@ -109,20 +109,20 @@ sections:
|
|||
# https://github.com/github/releases/issues/2739
|
||||
- |
|
||||
To improve code security and simplify the process of updating vulnerable dependencies, more users can receive automatic pull requests with dependency updates.
|
||||
|
||||
|
||||
- GitHub Actions authors can automatically update dependencies within workflow files.
|
||||
- Dart or Flutter developers who use Pub can automatically update dependencies within their projects.
|
||||
|
||||
|
||||
For more information, see "[About Dependabot security updates](/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates)."
|
||||
|
||||
# https://github.com/github/releases/issues/2438
|
||||
# https://github.com/github/releases/issues/2553
|
||||
- |
|
||||
Dart and JavaScript developers on an instance with the dependency graph enabled can receive Dependabot alerts for known vulnerabilities within a project's dependencies.
|
||||
|
||||
|
||||
- For Dart, the dependency graph detects `pubspec.lock` and `pubspec.yaml` files.
|
||||
- JavaScript developers who use Node.js and npm can receive alerts for known vulnerabilities within Yarn v2 and v3 manifests. This supplements the existing support for v1 manifests. The dependency graph detects `package.json`, and `yarn.lock` files.
|
||||
|
||||
|
||||
For more information, see the following articles.
|
||||
|
||||
- "[About the dependency graph](/code-security/supply-chain-security/understanding-your-software-supply-chain/about-the-dependency-graph)"
|
||||
|
|
@ -257,10 +257,9 @@ sections:
|
|||
- |
|
||||
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/managing-protected-branches/about-protected-branches#about-branch-protection-settings)."
|
||||
Repository administrators can ensure the security and stability of branches 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#lock-branch)." [Updated: 2023-04-28]
|
||||
|
||||
# https://github.com/github/releases/issues/2666
|
||||
- |
|
||||
|
|
@ -302,7 +301,7 @@ sections:
|
|||
# https://github.com/github/releases/issues/2702
|
||||
- |
|
||||
When a site administrator runs a command using administrative SSH access, the command is now logged. To help GitHub Support troubleshoot and debug, support bundles include a log containing these commands.
|
||||
|
||||
|
||||
# https://github.com/github/releases/issues/2538
|
||||
- |
|
||||
To simplify the discovery of events within enterprise, organization, or user audit logs, the search bar now displays a list of available filters.
|
||||
|
|
@ -450,7 +449,7 @@ sections:
|
|||
known_issues:
|
||||
- |
|
||||
During configuration of high availability, after you run `ghe-maintenance -s` in step 12 of [this documentation](/admin/enterprise-management/configuring-high-availability/creating-a-high-availability-replica#creating-a-high-availability-replica), the following error appears and maintenance mode is not enabled.
|
||||
|
||||
|
||||
```
|
||||
unable to access '/data/user/common/cluster.conf': Permission denied
|
||||
```
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче