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 を使用してリポジトリの作業を続けるには、いくつかの変更を行う必要があります。

       GitHubをポイントするようにリモート URL を更新します。 「[AUTOTITLE](/get-started/git-basics/managing-remote-repositories)」を参照してください。

認証方法を更新します。
- HTTPS 認証を使用するには、 personal access tokenを作成する必要があります。「個人用アクセストークンを管理する」を参照してください。
- SSH 認証を使用するには、既存の SSH キーを作成するか、 GitHubに追加する必要があります。「SSH を使用したGitHubへの接続」を参照してください。
企業または組織で 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 の作業項目にリンクさせる方法を参照してください。

ブランチ保護

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

          GitHub また、リポジトリの CODEOWNERS ファイル内のファイル、フォルダー、および glob パターンに基づいてレビュー担当者を自動的に割り当てることもできます。 「[AUTOTITLE](/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 の概要」をご覧ください。

GitHub Copilot

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

「GitHub Copilot のクイックスタート」を参照してください。

この記事で