Merge pull request #9053 from MicrosoftDocs/users/chcomley/copilot-integration-repos

v-dirichards · web-flow · commit 66b3bf7cf01c · 2026-03-24T12:49:49.000-05:00
Copilot integration - Azure Repos
diff --git a/docs/repos/git/branch-policies.md b/docs/repos/git/branch-policies.md
@@ -6,6 +6,7 @@ ms.assetid: 5D76697E-16A0-4048-91D1-806FE24C92A3
 ms.service: azure-devops-repos
 ms.topic: overview
 ms.custom: cross-service, devx-track-azurecli
+ai-usage: ai-assisted
 ms.date: 03/31/2022
 monikerRange: '<= azure-devops'
 ms.subservice: azure-devops-repos-git
@@ -15,6 +16,8 @@ ms.subservice: azure-devops-repos-git
 
 [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)]
 
+[!INCLUDE [ai-assistance-callout](../../includes/ai-assistance-callout.md)]
+
 Branch policies help teams protect their important [branches](./create-branch.md) of development. Policies enforce your team's code quality and change management standards. This article describes how to set and manage branch policies. For an overview of all repository and branch policies and settings, see [Git repository settings and policies](repository-settings.md).
 
 A branch with required policies configured can't be deleted, and requires pull requests (PRs) for all changes.
diff --git a/docs/repos/git/commit-history.md b/docs/repos/git/commit-history.md
@@ -10,6 +10,7 @@ ms.date: 03/14/2018
 monikerRange: '<= azure-devops'
 ms.subservice: azure-devops-repos-git
 ms.custom: sfi-image-nochange
+ai-usage: ai-assisted
 ---
 
 
@@ -18,6 +19,8 @@ ms.custom: sfi-image-nochange
 
 [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)]
 
+[!INCLUDE [ai-assistance-callout](../../includes/ai-assistance-callout.md)]
+
 ## Commit history view
 
 The commit history view shows you the history of all the commits for a particular branch in a repository. By default, all results are shown in reverse chronological order. 
diff --git a/docs/repos/git/complete-pull-requests.md b/docs/repos/git/complete-pull-requests.md
@@ -9,13 +9,16 @@ ms.date: 03/31/2022
 monikerRange: '<= azure-devops'
 ms.subservice: azure-devops-repos-git
 ms.custom: devx-track-azurecli
+ai-usage: ai-assisted
 ---
 
 # Complete, abandon, or revert pull requests
 
 [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)]
 [!INCLUDE [version-vs-gt-eq-2019](../../includes/version-vs-gt-eq-2019.md)]
 
+[!INCLUDE [ai-assistance-callout](../../includes/ai-assistance-callout.md)]
+
 Once all required reviewers approve your pull request (PR) and the PR meets all [branch policy](branch-policies.md) requirements, you can merge your changes into the target branch and [complete the PR](#complete-a-pull-request). Or if you decide not to proceed with the changes in the PR, you can [abandon the PR](#abandon-the-pr).
 
 To address reviewers' changes, and respond to and resolve review comments, see [Address comments](review-pull-requests.md#address-comments).
diff --git a/docs/repos/git/create-branch.md b/docs/repos/git/create-branch.md
@@ -8,13 +8,16 @@ ms.topic: how-to
 ms.date: 10/19/2022
 monikerRange: '<= azure-devops'
 ms.subservice: azure-devops-repos-git
+ai-usage: ai-assisted
 ---
 
 # Create a new Git branch
 
 [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)]
 [!INCLUDE [version-vs-gt-eq-2019](../../includes/version-vs-gt-eq-2019.md)]
 
+[!INCLUDE [ai-assistance-callout](../../includes/ai-assistance-callout.md)]
+
 The first commit in a new Git repo is the start of the `main` branch. As you work in the `main` branch, you make commits to record your work in that branch. Branching in Git occurs when you create a new line of development that diverges from a prior branch. You might choose to create a new branch to develop and test a new feature before adding it to your `main` branch. The recommended [Git workflow](gitworkflow.md) is to use a new branch for every feature or bugfix. When you switch between branches, Git almost instantly switches the version of your repo files to match the branch you selected. Your [commits](commits.md) are always saved to the current branch, and are isolated from commits in other branches.
 
 For an overview of the Git workflow, see [Azure Repos Git tutorial](gitworkflow.md).
diff --git a/docs/repos/git/forks.md b/docs/repos/git/forks.md
@@ -8,13 +8,16 @@ ms.topic: how-to
 ms.date: 10/19/2022
 monikerRange: '<= azure-devops'
 ms.subservice: azure-devops-repos-git
+ai-usage: ai-assisted
 ---
 
 # Forks
 
 [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)]
 [!INCLUDE [version-vs-gt-eq-2019](../../includes/version-vs-gt-eq-2019.md)]
 
+[!INCLUDE [ai-assistance-callout](../../includes/ai-assistance-callout.md)]
+
 Git repo forks are useful when people want to make experimental, risky, or concealed changes to a codebase, but those changes need to be isolated from the codebase in the original repo. A new fork is basically a new remote repo that shares the source code of the original repo.
 
 As an independent version, changes you make to your fork, such as adding commits or branches, are hidden from the original repo. If you want to merge your codebase changes into the original repo, you must create a [pull request](pull-requests.md) (PR) to request review and approval of those changes.
diff --git a/docs/repos/git/history.md b/docs/repos/git/history.md
@@ -8,13 +8,16 @@ ms.topic: overview
 ms.date: 07/30/2018
 monikerRange: '<= azure-devops'
 ms.subservice: azure-devops-repos-git
+ai-usage: ai-assisted
 ---
 
 
 # Understand Git history
 
 [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)]
 
+[!INCLUDE [ai-assistance-callout](../../includes/ai-assistance-callout.md)]
+
 Git stores history as a graph of snapshots &mdash; called commits &mdash; of the entire repository.
 Each commit also contains a pointer to one or more previous commits.
 Commits can have multiple parents, creating a history that looks like a graph instead of a straight line.
diff --git a/docs/repos/git/merging.md b/docs/repos/git/merging.md
@@ -8,13 +8,16 @@ ms.topic: tutorial
 ms.date: 10/19/2022
 monikerRange: '<= azure-devops'
 ms.subservice: azure-devops-repos-git
+ai-usage: ai-assisted
 ---
 
 # Resolve merge conflicts
 
 [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)]
 [!INCLUDE [version-vs-gt-eq-2019](../../includes/version-vs-gt-eq-2019.md)]
 
+[!INCLUDE [ai-assistance-callout](../../includes/ai-assistance-callout.md)]
+
 When you [merge or rebase](pulling.md#update-branches-with-merge-or-rebase), you're telling Git to integrate changes made on one branch with changes made on another. Often, Git completes a merge or rebase automatically without your assistance. However, if Git discovers that a change made on one branch conflicts with a change made on another, it prompts you to resolve the conflict. A merge conflict can occur when the merged branches edit the same file line differently, or when one branch modifies a file and another branch deletes it. The process for resolving merge conflicts is applicable to both Git merge and rebase.
 
 You can resolve merge conflicts in Visual Studio, or by using the command line and any text editor.
diff --git a/docs/repos/git/pr-status-policy.md b/docs/repos/git/pr-status-policy.md
@@ -8,13 +8,16 @@ ms.topic: how-to
 ms.date: 08/11/2020
 monikerRange: '<= azure-devops'
 ms.subservice: azure-devops-repos-git
+ai-usage: ai-assisted
 ---
 
 
 # Configure a branch policy for an external service 
 
 [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)]
 
+[!INCLUDE [ai-assistance-callout](../../includes/ai-assistance-callout.md)]
+
 Branch policies are a powerful feature to ensure high quality code in your repo by establishing requirements for all pull requests. External services can use the PR [Status API](/rest/api/azure/devops/git/pull%20request%20statuses) to post detailed status to your PRs. The branch policy for external services brings the ability for those 3rd party services to participate in the PR workflow and establish policy requirements. This article guides you through the process of configuring a branch policy for a service that is posting PR status. For more information about PR status, see [Customize and extend pull request workflows with pull request status](pull-request-status.md).
 
 [!INCLUDE [note-tfs-2018.2-update](includes/note-tfs-2018.2-update.md)]  
diff --git a/docs/repos/git/pull-requests.md b/docs/repos/git/pull-requests.md
@@ -9,13 +9,16 @@ ms.date: 02/15/2025
 monikerRange: '<= azure-devops'
 ms.subservice: azure-devops-repos-git
 ms.custom: devx-track-azurecli
+ai-usage: ai-assisted
 ---
 
 # Create pull requests
 
 [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)]
 [!INCLUDE [version-vs-gt-eq-2019](../../includes/version-vs-gt-eq-2019.md)]
 
+[!INCLUDE [ai-assistance-callout](../../includes/ai-assistance-callout.md)]
+
 Create pull requests (PRs) to change, review, and merge code in a [Git repository](creatingrepo.md). You can create PRs from branches in the upstream repository or from branches in your [fork](forks.md) of the repository. Your team can [review the PRs](review-pull-requests.md) and give feedback on changes. Reviewers can step through the proposed changes, leave comments, and vote to approve or reject the PRs. Depending on [branch policies](branch-policies.md) and other requirements, your PR might need to meet various criteria before you can [complete the PR](complete-pull-requests.md) and merge the changes into the target branch.
 
 For PR guidelines and management considerations, see [About pull requests](about-pull-requests.md).
diff --git a/docs/repos/git/rebase.md b/docs/repos/git/rebase.md
@@ -8,13 +8,16 @@ ms.topic: tutorial
 ms.date: 10/18/2022
 monikerRange: '<= azure-devops'
 ms.subservice: azure-devops-repos-git
+ai-usage: ai-assisted
 ---
 
 # Apply changes with rebase
 
 [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)]
 [!INCLUDE [version-vs-gt-eq-2019](../../includes/version-vs-gt-eq-2019.md)]
 
+[!INCLUDE [ai-assistance-callout](../../includes/ai-assistance-callout.md)]
+
 Git automatically maintains a [history](/devops/develop/git/understand-git-history) of development on a [branch](branch-policies-overview.md) by linking each new [commit](commits.md) to its predecessor. When you [merge](merging.md) one branch into another, the history can become less straightforward. For example, a [no-fast-forward merge](https://git-scm.com/docs/git-merge#_true_merge) combines divergent lines of development by creating a merge commit with multiple predecessors. Conversely, a Git [rebase](https://git-scm.com/docs/git-rebase) combines divergent lines of development without creating a merge commit, which results in a simpler commit history but loses information about the merge. Your choice of [merge type](pulling.md#update-branches-with-merge-or-rebase) is likely influenced by whether you want to preserve a record of the merge or simplify the commit history.
 
 This article discusses when to use a rebase instead of a no-fast-forward merge, and provides procedures for the following tasks:
diff --git a/docs/repos/git/repository-settings.md b/docs/repos/git/repository-settings.md
@@ -6,6 +6,7 @@ ms.assetid: 9336ed18-c239-4394-aa4c-64b6d01130f9
 ms.service: azure-devops-repos
 ms.topic: how-to
 ms.custom: cross-service, devx-track-azurecli
+ai-usage: ai-assisted
 monikerRange: '<= azure-devops' 
 ms.date: 08/08/2022
 ms.subservice: azure-devops-repos-git
@@ -15,6 +16,8 @@ ms.subservice: azure-devops-repos-git
 
 [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)]
 
+[!INCLUDE [ai-assistance-callout](../../includes/ai-assistance-callout.md)]
+
 There are several ways to customize your Azure Repos Git repositories by using branch and repository settings and policies. This article discusses repository-level settings and policies.
 
 - Repository settings and policies configure global options for all Git repositories for a project or organization, or for individual repositories.
diff --git a/docs/repos/git/review-pull-requests.md b/docs/repos/git/review-pull-requests.md
@@ -9,12 +9,15 @@ monikerRange: '<= azure-devops'
 ms.date: 08/03/2022
 ms.subservice: azure-devops-repos-git
 ms.custom: sfi-image-nochange
+ai-usage: ai-assisted
 ---
 
 # Review pull requests
 
 [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)]
 
+[!INCLUDE [ai-assistance-callout](../../includes/ai-assistance-callout.md)]
+
 When you create a [pull request](pull-requests.md) (PR) and specify required/optional reviewers, Azure Repos will notify the reviewers that your PR is ready for review. All required reviewers must approve the changes in your PR before the changes can merge into the target branch. For PRs that change critical branches like the `main` branch, your team might have created [branch policies](branch-policies.md) that specify the reviewers or require a minimum number of reviewers. If branch policies add optional reviewers to your PR, you can keep them, require them, or remove them. If branch policies add required reviewers to your PR, you can't make them optional or remove them. For information about assigning reviewers through branch policies, see [Automatically include code reviewers](branch-policies.md#include-code-reviewers).
 
 If you're reviewing a PR, try to give constructive feedback that's precise and easy to understand. For more information on review feedback, see [Pull request feedback](about-pull-requests.md#quality-feedback-for-pull-requests). This article describes how to review pull requests in Azure DevOps.
diff --git a/docs/repos/git/set-git-repository-permissions.md b/docs/repos/git/set-git-repository-permissions.md
@@ -7,12 +7,15 @@ ms.topic: quickstart
 monikerRange: '<= azure-devops'
 ms.date: 04/14/2021
 ms.subservice: azure-devops-repos-git
+ai-usage: ai-assisted
 ---
 
 # Set Git repository permissions 
 
 [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)]
 
+[!INCLUDE [ai-assistance-callout](../../includes/ai-assistance-callout.md)]
+
 Manage access to repositories to lock down who can contribute to your source code and manage other features.  You can set permissions across all Git repositories by making changes to the top-level **Git repositories** entry. Individual repositories inherit permissions from the top-level **Git Repositories** entry. 
 
 > [!NOTE]   
diff --git a/docs/repos/git/view-pull-requests.md b/docs/repos/git/view-pull-requests.md
@@ -9,13 +9,16 @@ ms.date: 03/31/2022
 monikerRange: '<= azure-devops'
 ms.subservice: azure-devops-repos-git
 ms.custom: devx-track-azurecli
+ai-usage: ai-assisted
 ---
 
 # View, filter, and open pull requests
 
 [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)]
 [!INCLUDE [version-vs-gt-eq-2019](../../includes/version-vs-gt-eq-2019.md)]
 
+[!INCLUDE [ai-assistance-callout](../../includes/ai-assistance-callout.md)]
+
 You create pull requests (PRs) to [review](review-pull-requests.md) and [merge](complete-pull-requests.md) code changes in a [Git repository on Azure Repos](../../organizations/projects/create-project.md#add-a-repository-to-your-project). Team members and stakeholders can review changes and give feedback before merging the code into the target branch. Reviewers can also comment on changes and vote to approve or reject the code.
 
 Teams can require PRs for any changes on protected branches, and set [branch policies](branch-policies.md) to require certain PRs to meet specific criteria. 
