# Azure DevOpsとGitHubの主な違い

リポジトリ アクセス、認証、プル要求などのコア ワークフローは、Azure DevOps から GitHub に移行した後で異なります。

Azure DevOps から GitHub に移行した組織のメンバーである場合、このガイドでは、移行を可能な限りスムーズにするためにワークフローの変更について説明します。

## 構造

Azure DevOpsでは、リポジトリは **team プロジェクト**内に入れ子になっているため、環境の構造は次のようになります。

* 組織
  * チーム プロジェクト
    * リポジトリ
  * チーム プロジェクト
    * リポジトリ

チームプロジェクトからアクセス許可と表示の流れが行われます。

GitHub 構造が異なります。 リポジトリは、チームも含まれる **組織**内に直接入れ子になります。

* エンタープライズ アカウント
  * 組織
    * チーム
    * リポジトリ
  * 組織
    * チーム
    * リポジトリ

アクセス許可と可視性は、組織のメンバーシップ、チーム メンバーシップ、および個々のアクセス許可の組み合わせによって決まります。

Azure DevOpsでリポジトリをグループ化するために使用されるチーム プロジェクトの概念は、GitHub には存在せず、GitHub 内の組織をチーム プロジェクトと同等として扱うことをお勧めしません。

最初は、移行された各組織が GitHub にリポジトリの長い一覧を持っている場合がありますが、組織のメンバーのチームを介してアクセスとアクセス許可を付与できるため、組織のリポジトリを簡単に移動できます。

## 認証、アクセス許可、チーム

GitHubへの認証には 2 つの方法があります。 使用する方法は、エンタープライズ アカウントの構成方法によって異なります。

エンタープライズ アカウントで Enterprise Managed Users を使用している場合は、ID プロバイダー (Entra ID など) を使用して GitHub にサインインし、エンタープライズ アカウントに関連付けられた **プロビジョニング済み** アカウントを使用します。

それ以外の場合は、 **個人用**GitHub アカウントを使用します。 そのアカウントは、エンタープライズ アカウントと、作業するすべての組織に招待されます。 エンタープライズ アカウントが追加の SAML アクセス制限で構成されている場合、個人用アカウントは IdP に **リンク** されます。 エンタープライズ アカウント内のリソースにアクセスする必要がある場合は、IdP で認証するように求められます。

GitHub上の企業では、リポジトリはパブリック、プライベート、または内部にすることができます。 プライベート リポジトリは、明示的なアクセス権を持つユーザーとチームにのみ表示され、内部リポジトリは企業のすべてのメンバーに対して表示されますが、社外のユーザーには表示されません。 内部リポジトリは、同じ企業内の複数の組織がコードを検出して再利用する必要がある場合に便利です。 企業で Enterprise Managed Usersを使用している場合、ユーザー アカウントはパブリック リポジトリやその他のパブリック コンテンツを作成できません。

## Git の使用

Git を使用してリポジトリの作業を続けるには、いくつかの変更を行う必要があります。

1. GitHubをポイントするようにリモート URL を更新します。 「[リモートリポジトリを管理する](/ja/get-started/git-basics/managing-remote-repositories)」を参照してください。
2. 認証方法を更新します。
   * HTTPS 認証を使用するには、 personal access tokenを作成する必要があります。 「[個人用アクセス トークンを管理する](/ja/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)」を参照してください。
   * SSH 認証を使用するには、既存の SSH キーを作成するか、 GitHubに追加する必要があります。 「[SSH を使用したGitHubへの接続](/ja/authentication/connecting-to-github-with-ssh)」を参照してください。
3. 企業または組織で SAML シングル サインオン (SSO) を使用している場合は、リソースにアクセスする前に、 personal access token または SSH キーを承認する必要があります。

## プル リクエスト フロー

コードベースが GitHub でホストされるようになったので、 GitHub リポジトリに作成された pull request を使用して変更を提案します。

企業が Azure Boards と Pipelines を統合している場合、これらはどちらも GitHub で機能します。 コミット メッセージと pull request で作業項目を引き続き参照できます。 たとえば、 `Fix login bug (AB#1234)`と指定します。

Azure Boardsで作業項目を引き続き表示および管理できます。 また、ブランチ、コミット、プル要求を、Azure内から作業項目にリンクすることもできます。 Microsoft Learn の [GitHub のコミット、プルリクエスト、ブランチ、および課題を Azure Boards の作業項目にリンクさせる方法](https://learn.microsoft.com/en-us/azure/devops/boards/github/link-to-from-github) を参照してください。

## ブランチ保護

リポジトリへの管理者アクセス権を持つユーザーは、\*\*\*\* のGitHubを構成できます。 これらは、Azure DevOpsの**ブランチ ポリシー**に似ていて、承認レビュー担当者の最小数、成功した状態チェック、署名されたコミットの要求などのルールを設定します。

GitHub また、リポジトリの CODEOWNERS ファイル内のファイル、フォルダー、および glob パターンに基づいてレビュー担当者を自動的に割り当てることもできます。 「[コードオーナーについて](/ja/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)」を参照してください。

## パッケージと成果物

Azure DevOpsでは、Azure Artifactsを使用してパッケージ (NuGet パッケージ、npm パッケージ、Maven パッケージなど) を発行および使用し、Azure Pipelinesによって生成されたビルド 成果物を格納している可能性があります。

GitHubでは、パッケージは通常、GitHub Packagesに発行され、リポジトリまたは組織に関連付けられます。 企業が移行を完了した方法によっては、パッケージを引き続きAzure Artifactsに発行したり、パッケージを GitHub Packages に移動したり、両方の組み合わせを使用したりできます。

移行後に依存関係を復元できなくなった場合は、パッケージ ソースの構成を確認してください。 たとえば、 `nuget.config`、 `.npmrc`、 `settings.xml`、パイプライン構成などのファイル内のレジストリ URL または資格情報を更新する必要がある場合があります。

詳しくは、「[GitHub Packages の概要](/ja/packages/learn-github-packages/introduction-to-github-packages)」をご覧ください。

## GitHub Copilot

GitHubでリポジトリをホストすると、Copilotの能力を最大限に引き出します。 コードベースでは、Copilotで質問に回答したり、pull request で確認して提案したり、Copilot Chatを使用してユーザーに代わって変更を加えるために必要なすべてのコンテキストをCopilot cloud agentに提供します。

「[GitHub Copilot のクイック スタート](/ja/copilot/get-started/quickstart)」を参照してください。