Merge branch 'main' into patch-2

Author: EoinTrial

CHANGELOG.md

@@ -1,5 +1,14 @@
 # Docs changelog
 
+**13 April 2026**
+
+To coincide with the release of the ability to [steer your Copilot CLI sessions remotely](https://github.blog/changelog/2026-04-13-remote-control-cli-sessions-on-web-and-mobile-in-public-preview/) (from GitHub.com, or from GitHub Mobile), we have added these new articles:
+
+* _Conceptual information:_ [About remote access to GitHub Copilot CLI sessions](https://docs.github.com/copilot/concepts/agents/copilot-cli/about-remote-access)
+* _How-to information:_ [Steering a GitHub Copilot CLI session from another device](https://docs.github.com/copilot/how-tos/copilot-cli/steer-remotely)
+
+<hr>
+
 **9 April 2026**
 
 We've added a conceptual article to the Copilot CLI documentation explaining the context window, compaction, and checkpoints.

assets/images/help/code-quality/invoke-cloud-agent.png

@@ -515,7 +515,16 @@ on:
 
 Runs your workflow when activity on a pull request in the workflow's repository occurs. For example, if no activity types are specified, the workflow runs when a pull request is opened or reopened or when the head branch of the pull request is updated. For activity related to pull request reviews, pull request review comments, or pull request comments, use the [`pull_request_review`](#pull_request_review), [`pull_request_review_comment`](#pull_request_review_comment), or [`issue_comment`](#issue_comment) events instead. For information about the pull request APIs, see [AUTOTITLE](/graphql/reference/objects#pullrequest) in the GraphQL API documentation or [AUTOTITLE](/rest/pulls).
 
-Note that `GITHUB_SHA` for this event is the last merge commit of the pull request merge branch. If you want to get the commit ID for the last commit to the head branch of the pull request, use `github.event.pull_request.head.sha` instead.
+Note that `GITHUB_SHA` for this event is the last merge commit of the pull request merge branch. If you want to get the commit ID for the last commit to the head branch of the pull request, use `github.event.pull_request.head.sha` instead. For more information about merge branches, see [AUTOTITLE](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#pull-request-refs-and-merge-branches).
+
+### How the merge branch affects your workflow
+
+For open, mergeable pull requests, workflows triggered by the `pull_request` event set `GITHUB_REF` to the merge branch. Because `actions/checkout` uses `GITHUB_REF` by default, it checks out the merge branch. Your CI tests run against the merged result, not just the head branch alone:
+
+* `GITHUB_REF` is set to `refs/pull/PULL_REQUEST_NUMBER/merge`
+* `GITHUB_SHA` is the SHA of the merge commit on the merge branch
+
+To test only the head branch commits without simulating a merge, check out the head branch using `github.event.pull_request.head.sha` in your workflow.
 
 For example, you can run a workflow when a pull request has been opened or reopened.
 

content/actions/reference/workflows-and-actions/events-that-trigger-workflows.md

@@ -44,7 +44,6 @@ Your trial **won't** include access to {% data variables.product.prodname_ghe_se
 * {% data variables.product.prodname_github_codespaces %}
 * {% data variables.copilot.copilot_enterprise %}
 * {% data variables.copilot.copilot_for_business %}
-  * Contact {% data variables.contact.github_support %} to enable {% data variables.copilot.copilot_for_business %} during your trial.
 * {% data variables.product.prodname_sponsors %}
 * Paid {% data variables.product.prodname_marketplace %} apps
 * {% data variables.product.prodname_github_connect %}

content/admin/overview/setting-up-a-trial-of-github-enterprise-cloud.md

@@ -15,6 +15,9 @@ category:
 ---
 {% data reusables.gpg.desktop-support-for-commit-signing %}
 
+> [!TIP]
+> To configure your Git client to sign tags by default for a local repository, in Git versions 2.23.0 and above, run `git config tag.gpgsign true`. To sign all tags by default in any local repository on your computer, run `git config --global tag.gpgsign true`.
+
 1. To sign a tag, add `-s` to your `git tag` command.
 
    ```shell

content/authentication/managing-commit-signature-verification/signing-tags.md

@@ -13,6 +13,9 @@ category:
 
 ## Metered or usage-based billing options
 
+> [!NOTE]
+> Prepaid credit/debit cards are not accepted as a valid form of payment.
+
 The supported payment methods for metered billing:
 
 * Invoice – Managed accounts only

content/billing/reference/supported-payment-methods.md

@@ -68,6 +68,8 @@ If you configure {% data variables.product.prodname_code_scanning %} using {% da
 
 When {% data variables.product.prodname_code_scanning %} reports data-flow alerts, {% data variables.product.prodname_dotcom %} shows you how data moves through the code. {% data variables.product.prodname_code_scanning_caps %} allows you to identify the areas of your code that leak sensitive information, and that could be the entry point for attacks by malicious users.
 
+{% data reusables.code-scanning.track-alert-in-issue %}
+
 ### About alerts from multiple configurations
 
 You can run multiple configurations of code analysis on a repository, using different tools and targeting different languages or areas of the code. Each configuration of {% data variables.product.prodname_code_scanning %} generates a unique set of alerts. For example, an alert generated using the default {% data variables.product.prodname_codeql %} analysis with {% data variables.product.prodname_actions %} comes from a different configuration than an alert generated externally and uploaded via the {% data variables.product.prodname_code_scanning %} API.

content/code-security/concepts/code-scanning/about-code-scanning-alerts.md

@@ -0,0 +1,39 @@
+---
+title: Code scanning alert tracking using issues
+shortTitle: Alert tracking with issues
+intro: Connect security findings to your team's workflow by linking {% data variables.product.prodname_code_scanning %} alerts to issues for tracking and collaboration.
+permissions: People with write access for the repository can link {% data variables.product.prodname_code_scanning %} alerts to issues.
+versions:
+  feature: code-scanning-link-alert-to-issue
+contentType: concepts
+category:
+  - Find and fix code vulnerabilities
+---
+
+{% data reusables.code-scanning.alert-tracking-with-issues-preview-note %}
+
+{% data reusables.code-scanning.enterprise-enable-code-scanning %}
+
+## How alert-to-issue linking works
+
+When {% data variables.product.prodname_code_scanning %} identifies a vulnerability in your code, you can link the alert to a {% data variables.product.prodname_dotcom %} **issue** to track remediation work. This brings security fixes into your existing planning and project management workflow, making vulnerabilities visible in sprint planning, project boards, and team backlogs.
+
+Each alert can link to a single issue, while each issue can track up to 50 different alerts. This flexibility lets you group related vulnerabilities or track them individually, depending on your team's workflow.
+
+You can link alerts to issues in any repository where you have access and {% data variables.product.prodname_github_issues %} is enabled, not just the repository where the alert was found. This is useful when you track work in a central repository or use a separate issue tracker for security fixes.
+
+## Understanding synchronization behavior
+
+**Alert and issue statuses are not automatically synchronized.** Changes you make to an alert do not update the linked issue, and vice versa. This means:
+
+* When you fix the vulnerability and the alert automatically closes, the linked issue remains open until you manually close it.
+* When you close or reopen an issue, the alert status stays unchanged.
+* When you delete an issue, the link is removed from the alert page and alert list, but the alert itself remains open.
+
+## Best practices for managing linked alerts and issues
+
+**Track remediation progress clearly.** When you commit a fix, add a comment to the linked issue noting that the code is updated. After the next {% data variables.product.prodname_code_scanning %} run confirms the alert is closed, manually close the issue.
+
+**Use labels to show status.** Create issue labels like "code-fixed-awaiting-scan" or use project fields to indicate when a vulnerability is fixed but the issue is waiting for final verification and closure.
+
+**Assign responsibility.** Use issue assignees to make it clear who owns the remediation work, especially when security and development teams need to coordinate.

content/code-security/concepts/code-scanning/code-scanning-alert-tracking-using-issues.md

@@ -15,7 +15,7 @@ category:
 
 ## How {% data variables.copilot.copilot_autofix_short %} works
 
-{% data variables.copilot.copilot_autofix_short %} translates the description and location of an alert into code changes that may fix the alert. It interfaces with the large language model {% data variables.copilot.copilot_gpt_51 %} from OpenAI, which has sufficient generative capabilities to produce both suggested fixes in code and explanatory text for those fixes.
+{% data variables.copilot.copilot_autofix_short %} translates the description and location of an alert into code changes that may fix the alert. It interfaces with the large language model {% data variables.copilot.copilot_gpt_53_codex %} from OpenAI, which has sufficient generative capabilities to produce both suggested fixes in code and explanatory text for those fixes.
 
 ## Enabling and managing {% data variables.copilot.copilot_autofix_short %}
 

content/code-security/concepts/code-scanning/copilot-autofix-for-code-scanning.md

@@ -17,6 +17,7 @@ children:
   - /setup-types
   - /about-integration-with-code-scanning
   - /sarif-files
+  - /code-scanning-alert-tracking-using-issues
   - /merge-protection
   - /multi-repository-variant-analysis
   - /codeql