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

Forking ワークフローは、よく使用される他の Git ワークフローとは根本的に異なっています。

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

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

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

Forking ワークフローの主な長所は、貢献内容の統合を、全員が 1 つの中央リポジトリにプッシュする必要なく行えることです。

開発者は自分のサーバー側リポジトリにプッシュし、プロジェクトの保守担当者だけが公式リポジトリにプッシュできます。

これで保守担当者は、公式コードベースへの書き込みアクセスを付与することなく、どの開発者からのコミットも受け付けることができます。

通常、forking ワークフローは、プロジェクト保守担当者の元のリポジトリにマージすることを目的としています。

結果として、信頼されていないサードパーティを含め、大規模な組織的チームが安全に共同作業を行うための、柔軟性の高い方法が提供される分散型ワークフローとなっています。

これはまた、オープンソースプロジェクトにとって理想的なワークフローになります。

しくみ

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

しかし、新しい開発者は、プロジェクトに関する作業を開始するときに、公式リポジトリを直接クローンすることはありません。

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

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

開発者は、サーバー側のコピーを作成した後に Git を複製し、そのコピーを自分のローカルマシンに取得します。

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

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

次に、pull request をメインリポジトリに提出します。そこから、更新を統合する準備ができたことがプロジェクトの保守担当者に通知されます。

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

このワークフローの手順例を次に示します。

この機能を公式のコードベースに統合するには、次のようにします。

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

フォークワークフローの "公式" リポジトリの概念は単なる規則であることを理解しておくことが重要です。

公式リポジトリであるために必要な唯一のことは、それがプロジェクトの保守担当者のリポジトリであるということです。

"フォークされた" リポジトリと "フォーク" は特別な操作ではないことに注意する必要があります。

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

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

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