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

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

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

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

フォークは、内部ソース ワークフローをサポートする優れた方法です。元のプロジェクトに直接書き込むアクセス許可がない場合に変更を提案するフォークを作成できます。 これらの変更を共有する準備ができたら、pull request を使用して簡単に元に戻します。

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

フォークは、アップストリームの (元の) リポジトリのすべてのコンテンツから開始します。 フォークを作成するときに、すべてのブランチを含めたり、既定のブランチのみに制限したりできます。

重要な注意事項:

• アクセス許可、ポリシー、またはビルド パイプラインはコピーされていません。
• 新しいフォークは、誰かが元のリポジトリを複製し、それを新しい空のリポジトリにプッシュしたかのように機能します。
• フォークが作成された後、新しいファイル、フォルダー、およびブランチは、プル要求が一緒に実行しない限り、リポジトリ間で共有されません。

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

プル要求は、フォークからアップストリーム、またはアップストリームからフォークまで、どちらの方向でも作成できます。 最も一般的な方法は、フォークからアップストリームです。

宛先リポジトリのアクセス許可、ポリシー、ビルド、および作業項目は、プル要求に適用されます。

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

• 小規模な Teams (2 ~ 5 人の開発者): 1 つのリポジトリで作業することをお勧めします。 すべてのユーザーがトピック ブランチで作業し、メイン ブランチをブランチ ポリシーで保護する必要があります。

• 大規模なチーム: チームが成長するにつれて、この配置を上回り、フォークワークフローに切り替えたくなるかもしれません。

• フォークを使用する場合:

  • リポジトリには、多くのカジュアルまたは頻度の低い共同作成者 (オープンソース プロジェクトなど) があります。
  • リポジトリへの直接コミット権限を持つのは、コア共同作成者だけです。
  • コアチーム外のコラボレーターにはフォークから作業してもらいたいです。
  • 作業をレビューする機会が得られるまで、変更を分離する必要があります。

forking ワークフロー

フォーク ワークフローの基本的な手順を次に示します。

1. フォークを作成します。
2. ローカルに複製します。
3. ローカルで変更を加え、ブランチにプッシュします。
4. アップストリームへのプル要求を作成して完了します。
5. フォークをアップストリームから最新版に同期します。

手順 1: フォークを作成する

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

手順 2: フォークをローカルに複製する

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

git clone {your_fork_url}
For convenience, after cloning, you'll want to add the upstream repository (where you forked from) as a remote named upstream:

```bash
git remote add upstream {upstream_url}

手順 3: 変更を行ってプッシュする

メインで直接作業することは可能です。結局のところ、このフォークはリポジトリのコピーです。 ただし、トピック ブランチでは次の理由から引き続き作業することをお勧めします。

• これにより、複数の独立したワークストリームを同時に維持できます。
• これにより、後で変更をフォークに同期するときの混乱が軽減されます。

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

手順 4: pull request を作成して完了する

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

手順 5: フォークを最新の状態に同期する

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

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

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

フォーク ワークフローの利点

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

このアプローチでは、次の機能が提供されます。

• 安全性: 変更はレビューされるまで分離されます。
• コラボレーション: 複数のユーザーが同時に異なる機能に取り組むことができます。
• 品質: すべての変更が同じレビュー プロセスを経る。
• 柔軟性: 共同作成者は、メイン リポジトリへの書き込みアクセス権を必要としません。