|
| 1 | +--- |
| 2 | +title: Key differences between Azure DevOps and GitHub |
| 3 | +shortTitle: Key differences |
| 4 | +intro: "Core workflows like repository access, authentication, and pull requests differ after moving from Azure DevOps to {% data variables.product.prodname_dotcom %}." |
| 5 | +versions: |
| 6 | + fpt: '*' |
| 7 | + ghec: '*' |
| 8 | +defaultTool: cli |
| 9 | +contentType: other |
| 10 | +--- |
| 11 | + |
| 12 | +If you're a member of an organization that has migrated from Azure DevOps to {% data variables.product.github %}, this guide will explain the changes in your workflows to make the migration as smooth as possible. |
| 13 | + |
| 14 | +## Structure |
| 15 | + |
| 16 | +In Azure DevOps, repositories are nested inside **team projects**, so the structure of your environment looks like this: |
| 17 | + |
| 18 | +* Organization |
| 19 | + * Team project |
| 20 | + * Repositories |
| 21 | + * Team project |
| 22 | + * Repositories |
| 23 | + |
| 24 | +Permissions and visibility flow from the team project. |
| 25 | + |
| 26 | +{% data variables.product.github %} is structured differently. Repositories are nested directly inside **organizations**, which also contain teams: |
| 27 | + |
| 28 | +* Enterprise account |
| 29 | + * Organization |
| 30 | + * Teams |
| 31 | + * Repositories |
| 32 | + * Organization |
| 33 | + * Teams |
| 34 | + * Repositories |
| 35 | + |
| 36 | +Permissions and visibility are determined by a combination of organization membership, team membership, and individual permissions. |
| 37 | + |
| 38 | +The concept of a team project, which is used to group repositories in Azure DevOps, does not exist in {% data variables.product.github %} and treating organizations in {% data variables.product.github %} as the equivalent of team projects is not recommended. |
| 39 | + |
| 40 | +While you may initially find each migrated organization on {% data variables.product.github %} has a long unorganized list of repositories, you can grant access and permissions via teams of organization members, which makes navigating the organization's repositories a lot easier. |
| 41 | + |
| 42 | +## Authentication, permissions, and teams |
| 43 | + |
| 44 | +There are two methods for authenticating to {% data variables.product.github %}. Which method you use will depend on how the enterprise account is configured. |
| 45 | + |
| 46 | +If your enterprise account uses {% data variables.product.prodname_emus %}, you'll sign in to {% data variables.product.github %} via your identity provider (for example, Entra ID) and use a **provisioned** account tied to the enterprise account. |
| 47 | + |
| 48 | +Otherwise, you'll use a **personal** {% data variables.product.github %} account. That account will be invited to the enterprise account and any organizations you'll work in. If the enterprise account is configured with additional SAML access restrictions, your personal account will be **linked** to your IdP. You'll be prompted to authenticate with the IdP when you need to access resources within the enterprise account. |
| 49 | + |
| 50 | +In an enterprise on {% data variables.product.prodname_dotcom %}, repositories can be public, private, or internal. Private repositories are only visible to people and teams with explicit access, and internal repositories are visible to all members of your enterprise but not to people outside the enterprise. Internal repositories are useful when multiple organizations in the same enterprise need to discover and reuse code. If your enterprise uses {% data variables.product.prodname_emus %}, user accounts cannot create public repositories or other public content. |
| 51 | + |
| 52 | +## Using Git |
| 53 | + |
| 54 | +To continue working on your repositories using Git, you'll need to make some changes. |
| 55 | + |
| 56 | +1. Update the remote URLs to point at {% data variables.product.github %}. See [AUTOTITLE](/get-started/git-basics/managing-remote-repositories). |
| 57 | +1. Update how you authenticate. |
| 58 | + * To use HTTPS authentication, you'll need to create a {% data variables.product.pat_generic %}. See [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens). |
| 59 | + * To use SSH authentication, you'll need to either create or add an existing SSH key to {% data variables.product.github %}. See [AUTOTITLE](/authentication/connecting-to-github-with-ssh). |
| 60 | +1. If your enterprise or organization uses SAML single sign-on (SSO), you must authorize your {% data variables.product.pat_generic %} or SSH key before it can access resources. |
| 61 | + |
| 62 | +## Pull request flow |
| 63 | + |
| 64 | +With your codebase now hosted on {% data variables.product.github %}, you'll propose changes using pull requests created in your {% data variables.product.github %} repositories. |
| 65 | + |
| 66 | +If your enterprise has integrated Azure Boards and Pipelines, these will both function with {% data variables.product.github %}. You can continue to reference work items in your commit messages and pull requests. For example: `Fix login bug (AB#1234)`. |
| 67 | + |
| 68 | +You can continue to view and manage your work items on Azure Boards. You can also link branches, commits, and pull requests to work items from within Azure. See [Link GitHub commits, pull requests, branches, and issues to work items in Azure Boards](https://learn.microsoft.com/en-us/azure/devops/boards/github/link-to-from-github) on Microsoft Learn. |
| 69 | + |
| 70 | +## Branch protections |
| 71 | + |
| 72 | +People with admin access to a repository can configure **branch protection rules** on {% data variables.product.github %}. These are similar to **branch policies** on Azure DevOps and set rules such as a minimum number of approving reviewers, successful status checks, and requiring signed commits. |
| 73 | + |
| 74 | +{% data variables.product.github %} also supports automatically assigning reviewers based on the file, folder, and glob patterns in a repository's CODEOWNERS file. See [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners). |
| 75 | + |
| 76 | +## Packages and artifacts |
| 77 | + |
| 78 | +In Azure DevOps, you may have used Azure Artifacts to publish and consume packages (for example, NuGet packages, npm packages, or Maven packages) and to store build artifacts produced by Azure Pipelines. |
| 79 | + |
| 80 | +On {% data variables.product.github %}, packages are typically published to {% data variables.product.prodname_registry %} and associated with a repository or organization. Depending on how your enterprise completed the migration, you may continue to publish packages to Azure Artifacts, move packages to {% data variables.product.prodname_registry %}, or use a combination of both. |
| 81 | + |
| 82 | +If you can no longer restore dependencies after the migration, check your package source configuration. For example, you may need to update a registry URL or credentials in files like `nuget.config`, `.npmrc`, `settings.xml`, or in your pipeline configuration. |
| 83 | + |
| 84 | +For more information, see [AUTOTITLE](/packages/learn-github-packages/introduction-to-github-packages). |
| 85 | + |
| 86 | +## {% data variables.product.prodname_copilot %} |
| 87 | + |
| 88 | +Hosting your repositories on {% data variables.product.github %} unlocks the full power of {% data variables.product.prodname_copilot_short %}. Your codebase provides {% data variables.product.prodname_copilot_short %} with all the context it needs to answer questions in {% data variables.copilot.copilot_chat_short %}, review and make suggestions in your pull requests, and even make changes on your behalf with {% data variables.copilot.copilot_coding_agent %}. |
| 89 | + |
| 90 | +See [AUTOTITLE](/copilot/get-started/quickstart). |
0 commit comments