1
0
mirror of synced 2025-12-19 18:10:59 -05:00

[Improvement]: Small security updates to core docs (1) - (Builders) #17059 (#54203)

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This commit is contained in:
Anne-Marie
2025-02-05 13:44:01 +00:00
committed by GitHub
parent b652d108d3
commit a4ab70af0c
6 changed files with 75 additions and 7 deletions

View File

@@ -49,6 +49,20 @@ you are able to push your local changes.
For more information on this error, see [AUTOTITLE](/get-started/using-git/dealing-with-non-fast-forward-errors).
{% ifversion secret-scanning-push-protection-for-users %}
## Resolving blocked commits
To maintain the security of the repository you're pushing to, {% data variables.product.github %}'s push protection automatically protects you from accidentally committing secrets to public repositories on {% data variables.product.prodname_dotcom_the_website %}. Exposed secrets can pose serious security risks to your repository and your supply chain.
If {% data variables.product.github %} detects that the commit you're attempting to push contains a supported secret, it blocks the push. In order to resolve the block, you should either:
* **Remove the secret** from your commit(s). For more information, see [Resolving a blocked push](/code-security/secret-scanning/working-with-secret-scanning-and-push-protection/working-with-push-protection-from-the-command-line#resolving-a-blocked-push).
* **Follow the provided URL** to see options to allow the push. For more information, see [Bypassing push protection](/code-security/secret-scanning/working-with-secret-scanning-and-push-protection/working-with-push-protection-from-the-command-line#bypassing-push-protection)
To learn more about push protection, see [AUTOTITLE](/code-security/secret-scanning/working-with-secret-scanning-and-push-protection/push-protection-for-users).
{% endif %}
## Pushing tags
By default, and without additional parameters, `git push` sends all matching branches

View File

@@ -22,10 +22,6 @@ Clear context in your pull requests helps reviewers quickly see what youve ch
Aim to create small, focused pull requests that fulfill a single purpose. Smaller pull requests are easier and faster to review and merge, leave less room to introduce bugs, and provide a clearer history of changes.
### Review your own pull request first
Review, build, and test your own pull request before submitting it. This will allow you to catch errors or typos that you may have missed, before others start reviewing.
### Provide context and guidance
Write clear titles and descriptions for your pull requests so that reviewers can quickly understand what the pull request does. In the pull request body, include:
@@ -38,6 +34,19 @@ To help reviewers, share the type of feedback you need. For example, do you need
If your pull request consists of changes to multiple files, provide guidance to reviewers about the order in which to review the files. Recommend where to start and how to proceed with the review.
### Review your own pull request first
Review, build, and test your own pull request before submitting it. This will allow you to catch errors or typos that you may have missed, before others start reviewing.
### Review for security
There are various tools available that can help you review your pull request for potential security issues before others review it. Reviewing for security helps to catch and resolve security issues early, and lets you highlight unresolved risks for others to review and advise on. For example, you can:
* Check the dependency diff to see if your pull request is introducing vulnerable dependencies. See [AUTOTITLE](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-dependency-changes-in-a-pull-request).
* Check the {% data variables.product.prodname_advisory_database %} to find additional context and information on vulnerable dependencies.
* Investigate and resolve any failing security checks or workflows, such as the dependency review action or the {% data variables.product.prodname_code_scanning %} results check. See [AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#about-the-dependency-review-action) and [AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/triaging-code-scanning-alerts-in-pull-requests#about-code-scanning-as-a-pull-request-check).{% ifversion code-scanning-autofix %}
* If your repository has set up {% data variables.product.prodname_code_scanning %} as a pull request check, use {% data variables.product.prodname_copilot_autofix %} to suggest fixes for security vulnerabilities in your code. See [AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/triaging-code-scanning-alerts-in-pull-requests#working-with-copilot-autofix-suggestions-for-alerts-on-a-pull-request).{% endif %}
## Keeping your team informed
Pull requests can do more than just document code changes—theyre also a powerful way to keep your team and manager informed about the status of your work. By making your progress visible in your pull requests, you can reduce the need for separate updates and ensure everyone stays aligned.

View File

@@ -22,15 +22,25 @@ You can request that contributors include an issue reference in their pull reque
## Defining code owners
You may want to make sure that specific individuals always review changes to certain code or files in your repository. For example, you may want a technical writer on your team to always review changes in the `docs` directory.
You may want to make sure that specific individuals always review changes to certain code or files in your repository. For example, you may want to ensure that a member of the security team always reviews changes to your `SECURITY.md` file or `dependabot.yml` file.
You can define individuals or teams that you consider responsible for code or files in a repository to be code owners. Code owners will automatically be requested for review when someone opens a pull request that modifies the files that they own. You can define code owners for specific types of files or directories, as well as for different branches in a repository. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).
## Using protected branches
You can use protected branches to prevent pull requests from being merged into important branches, such as `main`, until certain conditions are met. For example, you can require passing CI tests or an approving review. For more information, see [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches).
You can use protected branches to prevent pull requests from being merged into important branches, such as `main`, until certain conditions are met. For example, you can require an approving review, or require that all status checks are passing. See [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches).
{% ifversion push-rulesets %}
{% ifversion repo-rules %}
## Using rulesets
Working alongside protected branches, rulesets let you enforce policies across your repository, such as requiring status checks or workflows to pass before a pull request can be merged.
Rulesets are especially useful for maintaining repository security when combined with other automated security checks. For example:
* You can use rulesets to enforce the dependency review action, a workflow that blocks pull requests that are introducing vulnerable dependencies into your codebase. See [AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/enforcing-dependency-review-across-an-organization). {% ifversion code-scanning-merge-protection-rulesets %}
* If your repository is configured with {% data variables.product.prodname_code_scanning %}, you can use rulesets to set {% data variables.product.prodname_code_scanning %} merge protection, which prevents pull requests from being merged if there is a {% data variables.product.prodname_code_scanning %} alert of a certain severity, or if a {% data variables.product.prodname_code_scanning %} analysis is still in progress. See [AUTOTITLE](/code-security/code-scanning/managing-your-code-scanning-configuration/set-code-scanning-merge-protection).{% endif %}
{% endif %}{% ifversion push-rulesets %}
## Using push rulesets

View File

@@ -42,6 +42,8 @@ To simplify reviewing changes in a large pull request, you can filter the diff t
![Screenshot of the file filter dropdown menu. The menu is expanded and outlined in dark orange.](/assets/images/help/pull_requests/file-filter-menu.png)
You can also use the diff view to see which dependencies you are introducing or changing with your pull request, and whether the dependency versions contain security vulnerabilities. For more information, see [AUTOTITLE](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-dependency-changes-in-a-pull-request#reviewing-dependencies-in-a-pull-request).
## Reasons diffs will not display
* You've exceeded the total limit of files or certain file types. For more information, see [AUTOTITLE](/repositories/creating-and-managing-repositories/repository-limits#diff-limits).

View File

@@ -11,5 +11,6 @@ versions:
children:
- /commit-exists-on-github-but-not-in-my-local-clone
- /why-are-my-commits-linked-to-the-wrong-user
- /my-commit-is-blocked-by-push-protection
---

View File

@@ -0,0 +1,32 @@
---
title: My commit is blocked by push protection
intro: 'To keep your repository secure, push protection prevents you from accidentally committing secrets to the repository.'
versions:
fpt: '*'
ghes: '*'
ghec: '*'
shortTitle: Commit blocked by push protection
---
## Understanding why push protection has blocked your commit
Leaked secrets can pose serious security risks to your repository and your supply chain. Push protection prevents you from accidentally introducing secrets to your codebase where they could be exploited by malicious actors.
If the repository you're contributing to on {% data variables.product.github %} is secured by push protection, you'll encounter a push protection block whenever you:
* **Push commits** containing recognized secrets **from the command line** to the remote repository.
* **Commit changes** {% ifversion push-protection-block-uploads %}or upload files {% endif %}containing recognized secrets to a repository in the **{% data variables.product.github %} UI**. {% ifversion secret-scanning-push-protection-content-endpoints %}
* **Make certain requests** containing recognized secrets in **the REST API**.{% endif %}
## Resolving a push protection block
In order to resolve the block, you should remove the secret from the commit {% ifversion secret-scanning-push-protection-content-endpoints %}(or request){% endif %}. If you believe the secret is safe to push, you may be able to bypass the block. For more information on how to remove the secret or, if necessary, bypass the block, see:
* [AUTOTITLE](/code-security/secret-scanning/working-with-secret-scanning-and-push-protection/working-with-push-protection-from-the-command-line)
* [AUTOTITLE](/code-security/secret-scanning/working-with-secret-scanning-and-push-protection/working-with-push-protection-in-the-github-ui){% ifversion secret-scanning-push-protection-content-endpoints %}
* [AUTOTITLE](/code-security/secret-scanning/working-with-secret-scanning-and-push-protection/working-with-push-protection-from-the-rest-api){% endif %}
## Further reading
* [AUTOTITLE](/code-security/secret-scanning/introduction/about-push-protection)
* [AUTOTITLE](/code-security/secret-scanning/introduction/supported-secret-scanning-patterns)