フォークワークフローを調べる

フォークワークフローは、他の一般的な Git ワークフローとは根本的に異なります。

単一のサーバー側リポジトリを使用して "中央" コードベースとして機能するのではなく、すべての開発者にサーバー側リポジトリを提供します。

これは、各共同作成者が 2 つの Git リポジトリを持っていることを意味します。

フォークワークフローは、パブリックオープンソースプロジェクトでよく見られます。

フォークワークフローの主な利点は、すべてのユーザーが 1 つの中央リポジトリにプッシュしなくても、コントリビューションを統合できることです。

開発者はサーバー側リポジトリにプッシュし、公式リポジトリにプッシュできるのはプロジェクト保守管理者だけです。

これにより、メンテナは、公式のコードベースへの書き込みアクセス権を与えることなく、開発者からのコミットを受け入れます。

フォークワークフローは、通常、元のプロジェクトメンテナのリポジトリにマージすることを目的としています。

その結果、大規模で有機的なチーム (信頼されていないサードパーティを含む) が安全に共同作業を行うための柔軟な方法を提供する分散ワークフローが得られます。

これにより、オープンソースプロジェクトに最適なワークフローにもなります。

しくみ

他の Git ワークフローと同様に、フォークワークフローは、サーバーに格納されている公式のパブリックリポジトリから始まります。

しかし、新しい開発者がプロジェクトの作業を開始する場合、公式リポジトリを直接複製することはありません。

代わりに、公式リポジトリをフォークしてサーバー上にコピーを作成します。

この新しいコピーは、個人のパブリックリポジトリとして機能します。他の開発者はそれをプッシュすることはできませんが、そこから変更をプルできます (これが必要な理由がすぐにわかります)。

サーバー側のコピーを作成した後、開発者は git クローンを実行して、そのコピーをローカルコンピューターに取得します。

他のワークフローと同様に、プライベート開発環境として機能します。

ローカルコミットを発行する準備ができたら、公式のコミットではなく、パブリックリポジトリにコミットをプッシュします。

次に、プル要求をメインリポジトリに提出します。これにより、プロジェクトの保守担当者は、更新プログラムを統合する準備ができていることを認識できます。

pull request は、提供されたコードに問題がある場合に便利なディスカッションスレッドとしても機能します。

このワークフローのステップバイステップの例を次に示します。

この機能を公式のコードベースに統合するには:

この投稿はプロジェクトの一部になり、他の開発者は公式リポジトリからプルしてローカルリポジトリを同期する必要があります。

フォークワークフローの "公式" リポジトリの概念は単なる慣例であることを理解することが不可欠です。

公式リポジトリを作成する唯一のことは、それがプロジェクトメンテナーのリポジトリであるということです。

"フォークされた" リポジトリと "フォーキング" は特別な操作ではないことに注意してください。

フォークされたリポジトリは、標準の git clone コマンドを使用して作成されます。フォークされたリポジトリは、通常、Azure Repos などの Git サービスプロバイダーによって管理およびホストされる "サーバー側クローン" です。

フォークされたリポジトリを作成する一意の Git コマンドはありません。

複製操作は、基本的にリポジトリとその履歴のコピーです。