Repo sync

content/code-security/concepts/secret-security/secret-scanning.md

@@ -69,9 +69,7 @@ Beyond the default detection of partner and provider secrets, you can expand and
 
 ### About validity checks
 
-Validity checks help you prioritize which secrets to remediate first by verifying whether a detected secret is still active. When you enable validity checks, {% data variables.product.prodname_secret_scanning %} may contact the secret's issuing service to determine if the credential has been revoked.
-
-Validity checks are separate from {% data variables.product.prodname_secret_scanning %}'s partner program. While partner secrets are automatically reported to service providers for revocation, validity checks verify the status of secrets you manage in your own alerts. For more information, see [AUTOTITLE](/code-security/concepts/secret-security/validity-checks).
+Validity checks help you prioritize which secrets to remediate first by verifying whether a detected secret is still active. When you enable validity checks, {% data variables.product.prodname_secret_scanning %} may contact the secret's issuing service to determine if the credential has been revoked. For more information, see [AUTOTITLE](/code-security/concepts/secret-security/validity-checks).
 
 {% endif %}
 

content/copilot/how-tos/copilot-cli/customize-copilot/use-byok-models.md

@@ -1,6 +1,6 @@
 ---
-title: Using your own LLM models in GitHub Copilot CLI
-shortTitle: Use your own model provider
+title: Adding LLM models to GitHub Copilot CLI
+shortTitle: Add LLM models
 intro: 'Use a model from an external provider of your choice in {% data variables.product.prodname_copilot_short %} by supplying your own API key.'
 allowTitleToDifferFromFilename: true
 versions:
@@ -14,7 +14,7 @@ docsTeamMetrics:
   - copilot-cli
 ---
 
-You can configure {% data variables.copilot.copilot_cli_short %} to use your own LLM provider, also called BYOK (Bring Your Own Key), instead of {% data variables.product.github %}-hosted models. This lets you connect to OpenAI-compatible endpoints, Azure OpenAI, or Anthropic, including locally running models such as Ollama.
+You can configure {% data variables.copilot.copilot_cli_short %} to include models from an LLM provider of your choice—using BYOK (Bring Your Own Key)—in addition to the {% data variables.product.github %}-hosted models. This lets you connect to OpenAI-compatible endpoints, Azure OpenAI, or Anthropic, including locally running models such as Ollama.
 
 > [!NOTE]
 > This article is for users who want to configure their own LLM provider API key on their local machine. To set up custom models for users in an enterprise, see [AUTOTITLE](/copilot/how-tos/administer-copilot/manage-for-enterprise/enable-custom-models).
@@ -143,5 +143,5 @@ You can run {% data variables.copilot.copilot_cli_short %} in offline mode to pr
    ```shell
    export COPILOT_OFFLINE=true
    ```
-   
+
 1. {% data reusables.copilot.copilot-cli.start-cli %}

content/copilot/how-tos/github-copilot-app/use-byok-models.md

@@ -1,6 +1,6 @@
 ---
-title: Using your own LLM models in the GitHub Copilot app
-shortTitle: Use your own model provider
+title: Adding LLM models to the GitHub Copilot app
+shortTitle: Add LLM models
 intro: 'Connect a model from an external provider of your choice by supplying your own API key, then use the model in agent sessions.'
 allowTitleToDifferFromFilename: true
 product: '{% data reusables.gated-features.github-app %}<br><a href="https://github.com/features/ai/github-app" target="_blank" class="btn btn-primary mt-3 mr-3 no-underline"><span>Download {% data variables.copilot.github_copilot_app %}</span> {% octicon "link-external" height:16 %}</a>'
@@ -15,7 +15,7 @@ category:
 > [!NOTE]
 > Support to use your own model provider in the {% data variables.copilot.github_copilot_app %} is in {% data variables.release-phases.public_preview %} and subject to change.
 
-You can configure the {% data variables.copilot.github_copilot_app %} to use your own LLM provider, also called BYOK (Bring Your Own Key), instead of {% data variables.product.github %}-hosted models. You can set up your model provider when you first open the app or later in app settings.
+You can configure the {% data variables.copilot.github_copilot_app %} to include models from an LLM provider of your choice—using BYOK (Bring Your Own Key)—in addition to the {% data variables.product.github %}-hosted models. You can set up your model provider when you first open the app or later in app settings.
 
 You must sign in with a {% data variables.product.github %} account to use the app, but you do not need a {% data variables.product.prodname_copilot_short %} plan if you use your own model provider. If you do have a {% data variables.product.prodname_copilot_short %} plan, you can use both your own model provider and {% data variables.product.github %}-hosted models in the same app.
 

content/copilot/tutorials/stack-ai-generated-code-in-pull-requests.md

@@ -10,9 +10,6 @@ category:
   - Team collaboration
 ---
 
-> [!NOTE]
-> Stacked pull requests are in {% data variables.release-phases.public_preview %} and subject to change.
-
 Large pull requests are difficult to review and create bottlenecks, especially when AI helps you generate a high volume of code in a short time. Review quality also degrades as pull request size increases. Reviewers may skim the result, miss issues, or procrastinate and leave the pull request until it grows stale and develops merge conflicts.
 
 Stacked pull requests keep large code changes reviewable. 

content/pull-requests/get-started/about-stacked-prs.md

@@ -9,8 +9,6 @@ category:
   - Create pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 ## About stacked pull requests
 
 Stacked pull requests are two or more pull requests in the same repository, where:

content/pull-requests/get-started/stacked-prs-quickstart.md

@@ -9,8 +9,6 @@ category:
   - Create pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 {% data reusables.pull_requests.pr-stack-invitation %}
 
 {% data reusables.pull_requests.pr-stack-definition %}

content/pull-requests/how-tos/create-pull-requests/creating-stacked-pull-requests.md

@@ -9,8 +9,6 @@ category:
   - Create pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 Create stacked pull requests with the `gh stack` extension in {% data variables.product.prodname_cli %} or on the {% data variables.product.github %} website.  
 
 > [!NOTE]

content/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests.md

@@ -9,8 +9,6 @@ category:
   - Create pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 As you iterate on a stack, you often need to make changes in a lower layer, rebase to keep a linear history, or restructure its branches. The `gh stack` extension in {% data variables.product.prodname_cli %} handles these tasks with cascading operations that update every affected branch. See [AUTOTITLE](/pull-requests/reference/stacked-prs-cli-commands).
 
 ## Making changes to a lower layer

content/pull-requests/how-tos/merge-and-close-pull-requests/merging-stacked-pull-requests.md

@@ -9,8 +9,6 @@ category:
   - Merge and close pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 Stacked pull requests merge from the bottom (closest to the trunk) up. 
 
 * You can merge any number of pull requests at once, as long as they form a contiguous group starting from the lowest unmerged pull request. 
@@ -24,7 +22,7 @@ The merge box for a stacked pull request shows the status of the entire stack, n
 * The stack has a linear history.
 * The current pull request meets all branch protection requirements for the stack base, such as `main`.
 
-If the stack is not linear, for example, after changes were pushed to a lower branch or after the trunk moved ahead, a **Rebase stack** button will appear in the merge box and you'll need to rebase the stack before you can merge.
+If the stack is not linear, for example, after changes were pushed to a lower branch or after the trunk moved ahead, a **Rebase stack** button will appear in the merge box and you'll need to rebase the stack before you can merge. Rebasing the stack will generate signed commits, and retain approvals if a diff has not changed, even if you have the **dismiss stale approvals** rule enabled. 
 
 > [!NOTE]
 > * If you merge via the API and want to use stacked pull requests, you'll need use the asynchronous merge API for stacks. See [AUTOTITLE](/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously).
@@ -35,7 +33,7 @@ If the stack is not linear, for example, after changes were pushed to a lower br
 Stacks fully support merge queues. All pull requests in the stack are added to the queue in the correct order. If a pull request is removed or ejected from the queue, all pull requests above it in the stack are also removed. 
 
 > [!NOTE]
-> To keep a stack together, the merge queue allows the merge group to exceed its configured maximum size by up to 50 percent. If the stack is too large to fit within that buffer, it will automatically be split across consecutive merge groups.
+> To keep a stack together, the merge queue allows the merge group to exceed its configured maximum size by up to 50 percent. If the stack is too large to fit within that buffer, it will automatically be put into the next merge group as a single unit.
 
 ## Merging from the bottom up
 

content/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests.md

@@ -9,8 +9,6 @@ category:
   - Merge and close pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 Every pull request in a stack is evaluated as if it targets the base of the stack, such as `main`. This keeps quality consistent across every layer, but it also means a workflow can run many times for a single stack. This article explains how workflows run for a stack and how to reduce redundant CI usage.
 
 ## How workflows run for a stack

content/pull-requests/how-tos/merge-and-close-pull-requests/troubleshooting-stacked-pull-requests.md

@@ -9,8 +9,6 @@ category:
   - Merge and close pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 This article covers common issues you may encounter when working with stacked pull requests and how to resolve them. 
 
 ## A rebase reports a conflict

content/pull-requests/how-tos/review-pull-requests/reviewing-stacked-pull-requests.md

@@ -10,8 +10,6 @@ category:
   - Review pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 Each pull request in a stack shows only the diff for its layer. This means reviewers can request changes on any pull request independently. When a reviewer requests changes on a pull request mid-stack, you should make the fix on the branch that owns the change and rebase so the branches above it pick up your update.
 
 ## Addressing review feedback

content/pull-requests/reference/stacked-prs-cli-commands.md

@@ -9,8 +9,6 @@ category:
   - Create pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 The `gh stack` extension for {% data variables.product.prodname_cli %} creates and manages stacks of pull requests from your local repository. For an introduction to stacks, see [AUTOTITLE](/pull-requests/reference/stacked-pull-requests).
 
 ## Installation

content/pull-requests/reference/stacked-pull-requests-apis-and-webhooks.md

@@ -13,8 +13,6 @@ category:
   - Merge and close pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 The {% data variables.product.github %} REST and GraphQL APIs both expose stacked pull requests. The REST API supports reading and managing stacks, while the GraphQL API supports read-only queries.
 
 Use the API to read a pull request's stack membership or to build your own automation and integrations for stacked pull requests.

content/pull-requests/reference/stacked-pull-requests.md

@@ -9,8 +9,6 @@ category:
   - Create pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 {% data reusables.pull_requests.pr-stack-definition %}
 
 Every pull request in a stack is evaluated against rules for the **base of the stack** — typically `main` — regardless of which branch it directly targets. This means mid-stack pull requests are held to the same standard as the bottom pull request.
@@ -57,6 +55,15 @@ Stack metadata, such as the stack's base branch, is available in workflow expres
 
 For the full set of metadata fields and patterns to reduce redundant CI usage, see [AUTOTITLE](/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests).
 
+## Rebasing
+
+When a rebase is available or needed, the merge box will indicate this by displaying a **Rebase stack** button. For example, this may happen when changes to a pull request make the stack non-linear. When the bottom pull request is merged, a rebase happens automatically and you typically won't need to rebase manually.   
+
+When a stack is rebased, you can expect the following: 
+
+* Rebasing the stack generates signed commits. 
+* Rebasing a stack doesn't count as a new, reviewable commit if the diff does not change. Approvals are retained in this situation, even when the **Dismiss stale pull request approvals when new commits are pushed** rule is enabled.  
+
 ## Merge requirements
 
 Before a pull request in a stack can merge, all of the following must be true:
@@ -67,11 +74,13 @@ Before a pull request in a stack can merge, all of the following must be true:
 
 For example, in the stack `main ← PR1 ← PR2 ← PR3`, merging PR #3 requires PR #1 and PR #2 to also pass checks, have required reviews, and satisfy all branch protection rules.
 
+> [!NOTE] Stacked pull requests support merging with **bypass rules**, but only the bottom pull request can be merged this way. You cannot merge the whole stack with bypass rules. See [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#granting-bypass-permissions-for-your-branch-or-tag-ruleset)
+
 ## Merge methods
 
 Stacks support all three merge methods. In each case, the pull requests land as a single atomic operation:
 
-* **Merge commit** creates one merge commit for the entire group of pull requests being merged, preserving each pull request's full commit history.
+* **Merge commit** creates one merge commit for each pull requests being merged, preserving each pull request's full commit history.
 * **Squash** creates one clean, squashed commit per pull request. Merging `n` pull requests creates `n` squashed commits on the base branch.
 * **Rebase** replays the commits from each pull request onto the base branch, creating a linear history without merge commits.
 
@@ -80,7 +89,7 @@ Stacks support all three merge methods. In each case, the pull requests land as
 Stacks fully support merge queues. All pull requests in the stack are added to the queue in the correct order. If a pull request is removed or ejected from the queue, all pull requests above it in the stack are also removed. 
 
 > [!NOTE]
-> To keep a stack together, the merge queue allows the merge group to exceed its configured maximum size by up to 50 percent. If the stack is too large to fit within that buffer, it will automatically be split across consecutive merge groups.
+> To keep a stack together, the merge queue allows the merge group to exceed its configured maximum size by up to 50 percent. If the stack is too large to fit within that buffer, it will automatically be put into the next merge group as a single unit.
 
 ## Linear history
 

content/pull-requests/reference/use-other-tools-with-stacked-pull-requests.md

@@ -9,8 +9,6 @@ category:
   - Create pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 Stacked pull requests are built on standard Git branches and regular pull requests, so you can choose to use tools other than the `gh stack` CLI for your local workflow. If you manage branch chains with another tool, such as Jujutsu (jj), Sapling, or git-town, you can use the `gh stack link` command to open those branches as a stack on {% data variables.product.github %}. 
 
 The `gh stack link` command only calls the {% data variables.product.github %} API to create the stacked pull requests — it does not create any local tracking. If a branch already has an open pull request, `link` uses it; otherwise it creates a draft pull request with the correct base branch.

content/pull-requests/tutorials/roll-out-stacked-prs.md

@@ -10,9 +10,6 @@ category:
 - Create pull requests
 ---
 
-> [!NOTE]
-> Stacked pull requests are in {% data variables.release-phases.public_preview %} and subject to change.
-
 Stacked pull requests let developers break large changes into a chain of small, focused pull requests that build on each other. This approach can help your organization maintain review quality as developers produce more code, including with {% data variables.product.prodname_copilot_short %} and other coding agents.
 
 Stacked pull requests require **no setup or enablement**. If your team already uses pull requests, they can create a stack today. The steps below help you prepare your existing controls and support a smooth rollout, not turn a feature on.

content/pull-requests/tutorials/stack-code-changes-in-pull-requests.md

@@ -10,8 +10,6 @@ category:
   - Team collaboration
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 Large pull requests are difficult to review and create bottlenecks, especially when you generate a high volume of code in a short time. Review quality also degrades as pull request size increases. Reviewers may skim the result, miss issues, or procrastinate and leave the pull request until it grows stale and develops merge conflicts.
 
 Stacked pull requests keep large code changes reviewable.