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

5 分

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

最も一般的に、フォークは他のユーザーのプロジェクトに変更を提案するために使用されます。または、他のユーザーのプロジェクトをアイデアの開始点として使用します。

フォークは、すべてのファイル、コミット、(必要に応じて) ブランチを含むリポジトリの完全なコピーです。

フォークは、内部ソースワークフローをサポートする優れた方法です。元のプロジェクトに直接書き込むアクセス許可がない場合に変更を提案するフォークを作成できます。

これらの変更を共有する準備ができたら、pull request を使用してそれらをプロジェクトに貢献するのは簡単です。

フォークには何があるのか?

フォークは、アップストリーム (元の) リポジトリのすべての内容から始まります。

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

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

新しいフォークは、誰かが元のリポジトリを複製し、それを新しい空のリポジトリにプッシュしたかのように機能します。

フォークが作成された後、新しいファイル、フォルダー、ブランチは、プルリクエスト (PR) によって引き継がれない限り、リポジトリ間で共有されません。

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

最も一般的なアプローチは、フォークからアップストリームへのものでしょう。

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

ブランチとフォークの選択

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

すべてのユーザーがトピックブランチで作業し、メインをブランチポリシーで保護する必要があります。

チームの規模が大きくなるにつれて、今のこの方式を超えてフォークワークフローに切り替えたくなるかもしれません。

リポジトリに多数のカジュアルまたは頻度の低い委員会 (オープンソースプロジェクトなど) がある場合は、フォークワークフローをお勧めします。

通常、プロジェクトの主要な共同作成者のみがリポジトリに直接コミット権限を持ちます。

コアセットのメンバー以外のコラボレーターには、リポジトリのフォークから作業してもらうよう依頼すると良いでしょう。

また、作業を確認する機会が得られるまで、相手の変更内容は自身のものから隔離されます。

フォークワークフロー

フォークを作成します。
ローカルに複製します。
ローカルで変更を行い、ブランチにプッシュする。
PR を作成し、アップストリームに送信します。
フォークをアップストリームの最新の内容に同期させる。

フォークを作成する

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

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

手記

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

フォークをローカルにクローンする

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

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

git remote add upstream {upstream_url}

変更を作成してプッシュする

メインで直接作業することは可能です。結局のところ、このフォークはリポジトリのコピーです。

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

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

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

通常どおりに変更を行ってコミットします。変更が完了したら、origin（あなたのフォーク）にプッシュします。

PR を作成して完了する

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

PR の作成と完了を示す

大事な

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

フォークを最新の状態に同期する

PR がアップストリームに受け入れられたら、フォークにリポジトリの最新の状態が反映されていることを確認する必要があります。

アップストリームのメインブランチ（main がメイン開発ブランチであると仮定して）にリベースすることをお勧めします。

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

フォークワークフローを使用すると、変更を統合する準備ができるまで、メインリポジトリから変更を分離できます。準備ができたら、pull request を完了するのと同じくらい簡単にコードを統合できます。

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