Azure DevOps から GitHub に移行した組織のメンバーである場合、このガイドでは、移行を可能な限りスムーズにするためにワークフローの変更について説明します。
構造
Azure DevOps では、リポジトリは チーム プロジェクト内に入れ子になっているため、環境の構造は次のようになります。
- 組織
- チーム プロジェクト
- リポジトリ
- チーム プロジェクト
- リポジトリ
- チーム プロジェクト
チームプロジェクトからアクセス許可と表示の流れが行われます。
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 を更新します。 「リモートリポジトリを管理する」を参照してください。
- 認証方法を更新します。
- HTTPS 認証を使用するには、personal access token を生成する必要があります。 「個人用アクセス トークンを管理する」を参照してください。
- SSH 認証を使用するには、GitHub に既存の SSH キーを作成または追加する必要があります。 「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 の Azure Boards の作業項目への GitHub コミット、プル要求、ブランチ、および問題のリンク に関するページを参照してください。
ブランチ保護
リポジトリへの管理者アクセス権を持つユーザーは、GitHub で ブランチ保護規則 を構成できます。 これらは Azure DevOps の ブランチ ポリシー に似ていて、承認レビュー担当者の最小数、成功した状態チェック、署名されたコミットの要求などのルールを設定します。
GitHub では、リポジトリの CODEOWNERS ファイル内のファイル、フォルダー、glob パターンに基づいてレビュー担当者を自動的に割り当てることもできます。 「コードオーナーについて」を参照してください。
パッケージと成果物
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 に必要なすべてのコンテキストを提供します。そのコンテキストをもとに、Copilot チャット での質問に回答し、プルリクエストでのレビューと提案を行い、Copilot コーディングエージェント を用いてユーザーに代わって変更を加えることができます。
「GitHub Copilot のクイック スタート」を参照してください。