フォークワークフローを実装する

5 分

フォークは、リポジトリのコピーです。リポジトリをフォークすると、元のプロジェクトに対して大きな影響を与えることなく、変更を実験することができます。

フォークは通常、他のユーザーのプロジェクトに変更を提案するために使用されます。または、あなたのアイデアを実現するための出発点として、他のユーザーのプロジェクトを使用します。

フォークは、すべてのファイルやコミット、および必要な場合はブランチも含め、リポジトリの完全なコピーです。

フォークは、内部ソースワークフローをサポートする最適な方法です。元のプロジェクトに直接書き込むことができるアクセス許可を持っていない場合は、フォークを作成して提案できます。

これらの変更を共有する準備が整ったら、pull request を使用して、簡単に再参加できます。

フォークの内容

フォークは、アップストリームの (元の) リポジトリのすべてのコンテンツから開始します。

フォークを作成するときは、すべてのブランチを含めるか、既定のブランチのみに制限することができます。

アクセス許可、ポリシー、ビルドパイプラインは一切適用されません。

新しいフォークは、あるユーザーが元のリポジトリを複製し、それを新しい空のリポジトリにプッシュした場合と同様に機能します。

フォークが作成された後は、pull request (PR) による処理が行われない限り、新しいファイル、フォルダー、ブランチがリポジトリ間で共有されることはありません。

PR は、フォークからアップストリームまたはアップストリームからフォークのどちらの方向にも作成することができます。

最も一般的な方法は、フォークからアップストリームです。

コピー先リポジトリのアクセス許可、ポリシー、ビルドおよび作業項目が PR に適用されます。

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

小規模なチーム (2 から 5 人の開発者) では、1 つのリポジトリでの作業をお勧めします。

全員がトピックブランチで作業する必要があり、main はブランチポリシーで保護される必要があります。

チームの重要性が増すにつれ、あなたはこの配置がチームの規模に追いついていないことに気づき、forking ワークフローへ切り替えようとします。

リポジトリに多数の非公式または不定期の委員会 (オープンソースプロジェクトなど) がある場合は、forking ワークフローをお勧めします。

通常、リポジトリへの直接コミット権限を持つのは、プロジェクトのコア共同作成者のみです。

このようなコアの立場にはないコラボレーターにリポジトリのフォークから作業するように求めていた場合に役立ちます。

また、作業を詳しく確認する機会を得るまでは、これによりあなたの変更と他のユーザーの変更が分離されます。

forking ワークフロー

フォークを作成します。
ローカルに複製します。
ローカルで変更を加え、ブランチにプッシュします。
PR を作成して、アップストリームに向けて完成させます。
フォークをアップストリームから最新版に同期します。

フォークを作成する

フォークするリポジトリに移動して、[フォーク] を選択します。
名前を指定して、フォークの作成が必要なプロジェクトを選択します。リポジトリに多数のトピックブランチが含まれている場合は、既定のブランチのみをフォークすることをお勧めします。
省略記号を選択したら、[フォーク] を選択し、フォークを作成します。

フォークの作成を示す図。

Note

フォークを作成するプロジェクトには、リポジトリの作成アクセス許可が必要です。すべての共同作成者がリポジトリの作成アクセス許可を持っている、フォーク専用のプロジェクトを作成することをお勧めします。このアクセス許可の付与の例については、「Git リポジトリのアクセス許可を設定する」を参照してください。

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

フォークの準備ができたら、コマンドラインまたは Visual Studio などの IDE を使用して複製します。そのフォークが、複製元のリモートになります。

便宜上、複製後に、アップストリームリポジトリ (フォーク元の場所) を「アップストリーム」という名前のリモートとして追加する必要があります。

git remote add upstream {upstream_url}

変更を加えてプッシュする

main で直接作業することは可能です。最終的に、このフォークがリポジトリのコピーとなります。

ただし、引き続きトピックブランチで作業することをお勧めします。

これにより、複数の独立したワークストリームを同時に維持することができます。

また、後で変更をフォークに同期する場合は、混乱が軽減されます。

通常どおり、変更を加えてコミットします。変更が完了したら、それを複製元 (自分のフォーク) にプッシュします。

PR を作成して完了する

pull request を、フォークからアップストリームに開きます。すべてのポリシー、必要なレビュー担当者、およびビルドが、アップストリームリポジトリに適用されます。すべてのポリシーが満たされたら、PR を完了することができます。変更は、アップストリームリポジトリの永続的な一部になります。

PR を作成して完了する様子を示す図。

重要

読み取りアクセス許可を持つすべてのユーザーは、PR をアップストリームに開くことができます。 PR ビルドパイプラインが構成されている場合は、フォークで導入されたコードに対してビルドが実行されます。

フォークを最新版に同期する

PR がアップストリームに受け入れられた場合は、リポジトリの最新の状態がフォークに反映されていることを確認してください。

アップストリームの main ブランチを再配置することをお勧めします (main がメインの開発ブランチであることが前提です)。

git fetch upstream main
git rebase upstream/main
git push origin

forking ワークフローを使用すると、統合する準備が整うまでは、変更をメインのリポジトリから分離しておくことができます。準備ができたら、pull request を完了させるときのように簡単にコードを統合できます。

フォーク ワークフローを実装する