フォーク

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Visual Studio 2019 | Visual Studio 2022

Git リポジトリ フォークは、ユーザーがコードベースに対して実験的、危険、または機密の変更を行う必要があるが、それらの変更を元のリポジトリのコードベースから分離する必要がある場合に便利です。 新しいフォークは基本的に、新しいリモート リポジトリにプッシュされた元のリポジトリの複製です。 フォークは元のリポジトリとは独立しており、単一のブランチを指定しない限り完全なコピーです。

独立したコピーであるため、コミットやブランチの追加など、フォークに加えた変更は、元のリポジトリと共有されません。 コードベースの変更を元のリポジトリにマージする場合は、pull request (PR) を作成して、それらの変更のレビューと承認を要求する必要があります。

フォーク プロセスでは、アクセス許可、ポリシー、またはビルド パイプラインが元のリポジトリからフォークに移転されることはありません。

この記事では、Azure Repos Git リポジトリでのフォークの操作について説明し、GitHub リポジトリでフォークを管理する方法について説明する GitHub コンテンツへのリンクを提供します。

この記事では、次の方法について説明します。

• フォーク間でコードを共有する
• ブランチとフォークのいずれかを選択する
• リポジトリ フォークを有効にする
• フォークを作成する
• フォークをローカルに複製する
• フォークにローカル変更をプッシュする
• PR を作成して完了する
• フォークを同期する

Azure Repos にアクセスするための前提条件

• Repos を、Azure DevOps プロジェクト設定で有効にする必要があります。 Repos ハブと関連ページが表示されない場合は、Azure DevOps サービスのオンとオフの切り替えに関するページを参照して Repos を再度有効にしてください。

• プライベート プロジェクトのコードを表示するには、Basic 以上のアクセス レベルの Azure DevOps プロジェクト メンバーである必要があります。 パブリック プロジェクトの場合、誰でもコードを表示できます。

  • プロジェクトがない場合は、作成するか、無料でサインアップします。

  • プロジェクト メンバーでない場合は、追加してもらいます。

• プライベート プロジェクトのコードを複製または投稿するには、共同作成者セキュリティ グループのメンバーであるか、対応するアクセス許可が設定されている必要があります。 パブリック プロジェクトの場合、誰でもコードの複製と投稿ができます。 詳細については、パブリック プロジェクトとは何かに関するページを参照してください。

  Note

  パブリック プロジェクトの場合、利害関係者アクセス権を付与されたユーザーは、Azure Repos へのフル アクセス権があります。

フォーク間でコードを共有する

元のリポジトリは多くの場合、"上流" リポジトリと呼ばれます。 変更をマージするための PR は、フォークから上流または上流からフォークのどちらの方向にも作成することができます。 最も一般的な方向は、フォークから上流です。 コピー先リポジトリのアクセス許可、ポリシー、ビルドおよび作業項目が PR に適用されます。

ブランチとフォークのいずれかを選択する

2 人から 5 人までの開発者による小規模なチームでは、誰もが機能ブランチで作業でき、ブランチ ポリシーで既定のブランチを保護できるため、forking ワークフローが必要ない場合もあります。 ただし、チームが拡大してこの仕組みに収まらなくなった場合、forking ワークフローに切り替えることができます。

ご使用のリポジトリに、オープンソース プロジェクトにあるような多数の不定期または低頻度のコミッターが存在する場合、forking ワークフローをお勧めします。 通常、元のリポジトリへの直接コミット権限を持つのは、プロジェクトのコアの共同作成者のみです。 他の共同作成者は、その作業がコアの共同作成者によってレビューされる機会が得られるまで、forking ワークフローを使用して、提案した変更を分離する必要があります。

リポジトリ フォークを有効にする

Azure Repos Git リポジトリのフォークを有効にするには、「フォークを有効にする」を参照してください。

GitHub リポジトリのフォークを有効にするには、「Organization のフォーク ポリシーを管理する」を参照してください。

forking ワークフロー

forking ワークフローは、次のセクションで説明する 5 つの手順で構成されています。

1. フォークの作成
2. フォークをローカルに複製する
3. フォークにローカル変更をプッシュする
4. PR を作成して完了する
5. フォークを同期する

フォークを作成する

次の手順では、Azure Repos Git リポジトリをフォークする方法について説明します。

Note

Azure DevOps プロジェクトでリポジトリをフォークするには、そのプロジェクトのリポジトリの作成許可が必要です。 リポジトリ所有者は、フォーク専用のプロジェクトを作成し、すべての共同作成者にリポジトリの作成アクセス許可を割り当てることを検討する必要があります。 アクセス許可の設定の詳細については、「Git リポジトリのアクセス許可を設定する」を参照してください。

1. Web ブラウザーから、フォークする　Azure Repos Git リポジトリに移動します。 [リポジトリ]>[ファイル] を選択し、省略記号メニューから [フォーク] を選択して [フォーク] ダイアログを開きます。

   

2. [フォーク] ダイアログで、フォークされるリポジトリに名前を付け、フォークを作成するプロジェクトを選択し、フォークに含めるブランチを選択して、[フォーク] を選択します。 フォークにすべてのブランチを含めるか、既定のブランチだけを含めるかを指定できます。 リポジトリに複数のトピック ブランチが含まれている場合は、フォークに既定のブランチのみを含めることを検討してください。

   

GitHub リポジトリをフォークする方法については、「リポジトリをフォークする」を参照してください。

フォークをローカルに複製する

リポジトリをフォークしたら、フォークを複製して、コンピューター上のフォルダーにローカル コピーを作成します。 複製は、コマンド ラインから、または Visual Studio などの IDE を使用して実行できます。 リポジトリの複製の詳細については、「既存の Git リポジトリを複製する」を参照してください。

リモート リポジトリを複製すると、Git では、複製したリモート リポジトリの URL の短縮形としてエイリアス origin が割り当てられます。 便宜上、フォーク元のリポジトリに upstream という名前の別名をもう 1 つ追加し、これは上流リポジトリと呼ばれます。 次の手順では、upstream という別名を追加する方法について説明します。

ヒント

便宜上、Git コマンドでは、対応する URL の代わりに origin と upstream という別名を使用できます。

Visual Studio

Visual Studio で upstream エイリアスを追加するには、次の手順に従います。

1. メニュー バーで [ツール]>[オプション] の順に選択して、[オプション] ウィンドウを開きます。 [ソース管理]>[Git リポジトリの設定]>[リモート] の順に選択し、[追加] を選択して [リモートの追加] ダイアログを開きます。

   

2. [リモートの追加] ダイアログで、upstream という名前の新しいリモートを追加し、フォークしたリポジトリの Git クローン URL を入力します。 [保存] を選択します。

   

コマンド ライン

コマンド ラインで、ローカル リポジトリのルート フォルダーに移動し、次のコマンドを実行して upstream という名前の新しいリモートを追加します。 <clone URL> を、フォークしたリポジトリの Git クローン URL に置き換えます。

git remote add upstream <clone URL>

たとえば、git remote add upstream https://fiber-teams@dev.azure.com/fiber-teams/FiberTests/_git/FiberTests は upstream エイリアスを追加します。

既存の upstream 別名を編集するには、次のコマンドを実行します。

git remote set-url upstream <clone URL>

フォークにローカル変更をプッシュする

フォークすると、リモート リポジトリの個人用の独立したコピーが作成されます。 そのため、ユーザーは何の妨げもなく、ローカル複製の main ブランチで直接作業し、その作業をフォークの main ブランチにプッシュすることができます。 ただし、通常は作業に機能ブランチを使用することをお勧めします。 機能ブランチを使用すると、次のようになります。

• 複数の独立したワークストリームを同時に更新することができます。

• 共有する作業がブランチごとに個別のワークストリームに編成されるため、他のユーザーが作業を理解しやすくなります。

一般的な Git ワークフローには、次の手順が含まれます。

1. ローカルの機能ブランチまたはバグ修正ブランチを作成します。

2. 新しいブランチに変更を加え、作業をコミット します。 通常、ユーザーは機能またはバグ修正の作業を行うときに複数回のコミットを行います。

3. 機能ブランチまたはバグ修正ブランチをフォークにプッシュします。 フォークには origin という別名が付けられます。

変更をプッシュする方法については、「push を使用してコードを共有する」を参照してください。

PR を作成して完了する

Azure Repos で、フォークにプッシュした変更を元のリポジトリにマージするには、次の操作を行います。

1. 変更のレビューと承認を要求する PR を作成します。 PR を開いたら、PR ソース ブランチをフォーク内の機能ブランチまたはバグ修正ブランチに設定します。 PR のターゲット ブランチは、通常フォークしたリポジトリの main ブランチです。 そのリポジトリは上流リポジトリと呼ばれ、upstream という別名があります。

   次のスクリーンショットでは、Azure Repos で作成された PR の "ソース" リポジトリとブランチ、および "ターゲット" リポジトリとブランチを示しています。

   

   ブラウザー、Visual Studio、または Azure DevOps CLI を使用して PR を作成する方法の詳細については、PR の作成に関する記事を参照してください。

   重要

   上流リポジトリの読み取りアクセス許可を持つすべてのユーザーは、それに対する PR を開くことができます。 上流リポジトリに、PR の作成時に実行するように構成された PR ビルド パイプラインがある場合、PR によって導入された変更に対してビルドが実行されます。

2. PR を完了するには、必要なすべてのレビュー担当者が PR の変更を承認し、すべてのターゲット ブランチ ポリシーが満たされる必要があります。 PR の承認と完了時に、PR ソース ブランチの変更が PR ターゲット ブランチにマージされます。

GitHub PR を作成して完了する方法については、「pull request の作成」と「pull request のマージ」を参照してください。

フォークを同期する

PR によって、フォークからの変更が上流リポジトリのターゲット ブランチにマージされた後、上流リポジトリのターゲット ブランチから プル して、自分の変更と他の共同作成者による変更の両方を使用して、対応するローカル ブランチを更新できます。 これで、次の準備が整います。

• 更新されたローカル ブランチから新しい機能ブランチまたはバグ修正ブランチを作成します。

• 更新したローカル ブランチから origin にプッシュ して、フォークを更新します。

通常、上流リポジトリのターゲット ブランチは main です。 ローカルの main ブランチを直接編集していない場合 (機能ブランチで作業している場合)、アップストリーム ブランチ upstream/main からプルすると、マージ競合なしにローカルの main ブランチが更新されます。

次のステップ

push を使用してコードを共有するpull request のレビュー

関連記事

• Git リポジトリの初心者向け 詳細情報
• フェッチ、マージ、プルを使用してコードを更新する
• コミットを使用して作業を保存する