github · sau226 · May 24, 2025 · May 24, 2025 · May 24, 2025
diff --git a/content/actions/sharing-automations/reusing-workflows.md b/content/actions/sharing-automations/reusing-workflows.md
@@ -225,7 +225,7 @@ This example job below calls a reusable workflow and references the matrix conte
 
 ```yaml copy
 jobs:
-  ReuseableMatrixJobForDeployment:
+  ReusableMatrixJobForDeployment:
     strategy:
       matrix:
         target: [dev, stage, prod]

diff --git a/...nce/administering-your-instance-from-the-command-line/command-line-utilities.md b/...nce/administering-your-instance-from-the-command-line/command-line-utilities.md
@@ -849,7 +849,7 @@ nes set-node-adminaction approved HOSTNAME
 To revoke {% data variables.product.prodname_nes %}'s ability to take the node with hostname HOSTNAME offline:
 
 ```shell
-nes set-node-adminaction approved HOSTNAME
+nes set-node-adminaction none HOSTNAME
 ```
 
 To manually update a node's eligibility for re-addition to the cluster:

diff --git a/...e-managed-users/configuring-saml-single-sign-on-for-enterprise-managed-users.md b/...e-managed-users/configuring-saml-single-sign-on-for-enterprise-managed-users.md
@@ -73,7 +73,7 @@ To configure SAML SSO for your {% data variables.enterprise.prodname_emu_enterpr
    | ----------------- | ------------- | ------------------- |
    | Microsoft Entra ID | [Microsoft Learn](https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/github-enterprise-managed-user-tutorial) | [Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/saas-apps/github-enterprise-managed-user-ghe-com-tutorial) |
    | Okta | [AUTOTITLE](/admin/identity-and-access-management/configuring-authentication-for-enterprise-managed-users/configuring-saml-single-sign-on-with-okta-for-enterprise-managed-users) | [AUTOTITLE](/admin/identity-and-access-management/configuring-authentication-for-enterprise-managed-users/configuring-saml-single-sign-on-with-okta-for-enterprise-managed-users) |
-   | PingFederate | [AUTOTITLE](/admin/managing-iam/provisioning-user-accounts-with-scim/configuring-authentication-and-provisioning-with-pingfederate) ("Prerequisities" and "1. Configure SAML" sections) | [AUTOTITLE](/admin/managing-iam/provisioning-user-accounts-with-scim/configuring-authentication-and-provisioning-with-pingfederate) ("Prerequisities" and "1. Configure SAML" sections) |
+   | PingFederate | [AUTOTITLE](/admin/managing-iam/provisioning-user-accounts-with-scim/configuring-authentication-and-provisioning-with-pingfederate) ("Prerequisites" and "1. Configure SAML" sections) | [AUTOTITLE](/admin/managing-iam/provisioning-user-accounts-with-scim/configuring-authentication-and-provisioning-with-pingfederate) ("Prerequisites" and "1. Configure SAML" sections) |
 
    {% endrowheaders %}
 

diff --git a/...anaging-iam/understanding-iam-for-enterprises/about-enterprise-managed-users.md b/...anaging-iam/understanding-iam-for-enterprises/about-enterprise-managed-users.md
@@ -74,7 +74,7 @@ If you cannot use a single partner IdP for both authentication and provisioning,
 The profile name and email address of a {% data variables.enterprise.prodname_managed_user %} is provided by the IdP:
 * {% data variables.enterprise.prodname_managed_users_caps %} _cannot_ change their profile name or email address on {% data variables.product.prodname_dotcom %}.
 * The IdP can only provide one email address.
-* Changing a user's email address in your IdP will delink the user from the contribution history associated with the old email address.
+* Changing a user's email address in your IdP will unlink the user from the contribution history associated with the old email address.
 
 ## Managing roles and access
 

diff --git a/...billing-for-github-advanced-security/signing-up-for-github-advanced-security.md b/...billing-for-github-advanced-security/signing-up-for-github-advanced-security.md
@@ -1,6 +1,6 @@
 ---
 title: Signing up for {% data variables.product.prodname_GHAS %}
-intro: "You can sign up for {% data variables.product.prodname_GHAS %} products from your {% data variables.enterprise.enterprise_or_org %} account's settings to prevent data leaks and keep vulnerablities out of your codebase."
+intro: "You can sign up for {% data variables.product.prodname_GHAS %} products from your {% data variables.enterprise.enterprise_or_org %} account's settings to prevent data leaks and keep vulnerabilities out of your codebase."
 allowTitleToDifferFromFilename: true
 permissions: '{% ifversion fpt %}Organization{% else %}Enterprise{% endif %} owners can sign up for {% data variables.product.prodname_GH_cs_or_sp %}'
 product: '{% data reusables.gated-features.ghas-billing %}'

diff --git a/...king-with-dependabot/configuring-access-to-private-registries-for-dependabot.md b/...king-with-dependabot/configuring-access-to-private-registries-for-dependabot.md
@@ -153,7 +153,7 @@ updates:
 
 {% endraw %}
 
-## Supported private registeries
+## Supported private registries
 
 Examples of how to configure access to the private registries supported by {% data variables.product.prodname_dependabot %}.
 

diff --git a/...ode-security/dependabot/working-with-dependabot/dependabot-options-reference.md b/...ode-security/dependabot/working-with-dependabot/dependabot-options-reference.md
@@ -562,7 +562,7 @@ Define a specific branch to check for version updates and to target pull request
 When `target-branch` is defined:
 
 * Only manifest files on the target branch are checked for version updates.
-* All pull requests for version updates are opened targetting the specified branch.
+* All pull requests for version updates are opened targeting the specified branch.
 * Options defined for this `package-ecosystem` no longer apply to security updates because security updates always use the default branch for the repository.
 
 ## `vendor` {% octicon "versions" aria-label="Version updates" height="24" %} {% octicon "shield-check" aria-label="Security updates" height="24" %}

diff --git a/...ganization/fixing-security-alerts-at-scale/best-practice-fix-alerts-at-scale.md b/...ganization/fixing-security-alerts-at-scale/best-practice-fix-alerts-at-scale.md
@@ -29,7 +29,7 @@ For information about the developer experience, see [AUTOTITLE](/code-security/c
 
 ## Selecting security alerts for remediation
 
-Your first thought may be to identify all the most urgent alerts and create a security campaign to fix them. If your developers already have a good understanding of secure coding and are keen to remediate potential vulnerabilities, this could be a successful approach for your company. However, if you need to build up knowledge of secure coding and common vulnerabilities, you will benefit from a more stategic approach.
+Your first thought may be to identify all the most urgent alerts and create a security campaign to fix them. If your developers already have a good understanding of secure coding and are keen to remediate potential vulnerabilities, this could be a successful approach for your company. However, if you need to build up knowledge of secure coding and common vulnerabilities, you will benefit from a more strategic approach.
 
 For example, if you have many alerts for cross-site scripting vulnerabilities, you could:
 

diff --git a/content/code-security/security-overview/filtering-alerts-in-security-overview.md b/content/code-security/security-overview/filtering-alerts-in-security-overview.md
@@ -183,7 +183,7 @@ All {% data variables.product.prodname_code_scanning %} alerts have one of the c
 | Qualifier | Description |
 | -------- | -------- |
 |`is`|Display {% data variables.product.prodname_code_scanning %} alerts that are open (`open`) or closed (`closed`).|
-|`resolution`| Display {% data variables.product.prodname_code_scanning %} alerts closed as "false positive" (`false-postive`), "fixed" (`fixed`), "used in tests" (`used-in-tests`), or "won't fix" (`wont-fix`).|
+|`resolution`| Display {% data variables.product.prodname_code_scanning %} alerts closed as "false positive" (`false-positive`), "fixed" (`fixed`), "used in tests" (`used-in-tests`), or "won't fix" (`wont-fix`).|
 |`rule`|Display {% data variables.product.prodname_code_scanning %} alerts identified by the specified rule.|
 |`severity`|Display {% data variables.product.prodname_code_scanning %} alerts categorized as `critical`, `high`, `medium`, or `low` security alerts. Alternatively, displays {% data variables.product.prodname_code_scanning %} alerts categorized as `error`, `warning`, `note` problems.|
 |`sort`| Display alerts from newest to oldest (`created-desc`), oldest to newest (`created-asc`), most recently updated (`updated-desc`), or least recently updated (`updated-asc`).

diff --git a/content/code-security/security-overview/viewing-security-insights.md b/content/code-security/security-overview/viewing-security-insights.md
@@ -221,7 +221,7 @@ The "Pull request alerts fixed with autofix suggestions" metric shows the ratio
 {% endif %}
 
 {% else %}
-<!--The remainder of this article has content for the dashboard without Detection, Remediation, and Preventation tabs GHES 3.13-3.15-->
+<!--The remainder of this article has content for the dashboard without Detection, Remediation, and Prevention tabs GHES 3.13-3.15-->
 
 * [Alert trends graph](#alert-trends-graph)
 * [Age of alerts](#age-of-alerts)

diff --git a/.../code-security/trialing-github-advanced-security/explore-trial-code-scanning.md b/.../code-security/trialing-github-advanced-security/explore-trial-code-scanning.md
@@ -23,7 +23,7 @@ This article focuses on how you can combine these features with enterprise-level
 
 In contrast to {% data variables.product.prodname_secret_protection %}, where a single security configuration is typically applied to all repositories, you probably want to fine-tune the configuration of {% data variables.product.prodname_code_scanning %} for different types of repositories. For example, you might need to create additional configurations so that:
 
-* {% data variables.product.prodname_code_scanning_caps %} uses runners with a specific label to apply to repositories that require a specialized environment or that use private registeries.
+* {% data variables.product.prodname_code_scanning_caps %} uses runners with a specific label to apply to repositories that require a specialized environment or that use private registries.
 * {% data variables.product.prodname_code_scanning_caps %} is "Not set" to apply to repositories that need to use advanced setup or that require a third-party tool.
 
 For your trial, it's simplest to create a primary enterprise-level security configuration and apply it to your test repositories. Then you can create any additional security configurations you need and apply them to a subset of repositories selected using code language, custom property, visibility, and  other filter options. For more information, see [AUTOTITLE](/code-security/trialing-github-advanced-security/enable-security-features-trial) and [AUTOTITLE](/code-security/securing-your-organization/enabling-security-features-in-your-organization/applying-a-custom-security-configuration).
@@ -103,7 +103,7 @@ There are two levels of control:
 
 ## Engage developers in security remediation
 
-Security campaigns provide a way for security teams to engage with developers to remediate security technical debt. They also provide a practical way to combine education in secure coding with examples of vulnerable code in code that your developers are familar with. For more information, see [AUTOTITLE](/code-security/securing-your-organization/fixing-security-alerts-at-scale/about-security-campaigns) and [AUTOTITLE](/code-security/securing-your-organization/fixing-security-alerts-at-scale/best-practice-fix-alerts-at-scale).
+Security campaigns provide a way for security teams to engage with developers to remediate security technical debt. They also provide a practical way to combine education in secure coding with examples of vulnerable code in code that your developers are familiar with. For more information, see [AUTOTITLE](/code-security/securing-your-organization/fixing-security-alerts-at-scale/about-security-campaigns) and [AUTOTITLE](/code-security/securing-your-organization/fixing-security-alerts-at-scale/best-practice-fix-alerts-at-scale).
 
 ## Provide a secure development environment
 

diff --git a/...ng-a-copilot-agent-for-your-copilot-extension/context-passing-for-your-agent.md b/...ng-a-copilot-agent-for-your-copilot-extension/context-passing-for-your-agent.md
@@ -228,7 +228,7 @@ In the following example, the `type` field indicates that the reference has been
 To safeguard sensitive information, certain scenarios automatically prevent the passing of context to agents.
 If an organization has set content exclusion rules for {% data variables.product.prodname_copilot_short %}, files that fall under these rules will not be included in the context passed to agents.
 
-For more information on content exlusion rules, see [AUTOTITLE](/copilot/managing-copilot/configuring-and-auditing-content-exclusion/excluding-content-from-github-copilot).
+For more information on content exclusion rules, see [AUTOTITLE](/copilot/managing-copilot/configuring-and-auditing-content-exclusion/excluding-content-from-github-copilot).
 
 #### Large Files
 

diff --git a/content/enterprise-onboarding/feature-enhancements/about-enterprise-security.md b/content/enterprise-onboarding/feature-enhancements/about-enterprise-security.md
@@ -1,6 +1,6 @@
 ---
 title: 'About enterprise security'
-shortTitle: 'Learn about the security fetures available to your enterprise.'
+shortTitle: 'Learn about the security features available to your enterprise.'
 intro: 'Learn about the security features available to your enterprise.'
 versions:
   ghec: '*'

diff --git a/...anches-and-merges-in-your-repository/managing-rulesets/troubleshooting-rules.md b/...anches-and-merges-in-your-repository/managing-rulesets/troubleshooting-rules.md
@@ -21,7 +21,7 @@ If a branch or tag is targeted by rules restricting the metadata of commits, you
 
 When utilizing push rulesets, a maximum of 1000 reference updates are allowed per push. If your push exceeds this limit, it will be rejected. For more information see [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#creating-a-push-ruleset).
 
-Additonally, push rulesets apply to the "Create a blob", "Create a tree", and "Create or update file contents" endpoints in the REST API. See [AUTOTITLE](/rest/git/blobs?apiVersion=2022-11-28#create-a-blob), [AUTOTITLE](/rest/git/trees?apiVersion=2022-11-28#create-a-tree), and [AUTOTITLE](/rest/repos/contents?apiVersion=2022-11-28#create-or-update-file-contents).
+Additionally, push rulesets apply to the "Create a blob", "Create a tree", and "Create or update file contents" endpoints in the REST API. See [AUTOTITLE](/rest/git/blobs?apiVersion=2022-11-28#create-a-blob), [AUTOTITLE](/rest/git/trees?apiVersion=2022-11-28#create-a-tree), and [AUTOTITLE](/rest/repos/contents?apiVersion=2022-11-28#create-or-update-file-contents).
 
 ## Troubleshooting required status checks