フォーク型ワークフロー

フォーク型ワークフローは、他の一般的な Git ワークフローとは根本的に異なります。「中央」コードベースとして機能する単一のサーバーサイドリポジトリを使うのではなく、各々の開発者に独自のサーバーサイドリポジトリを割り当てます。つまり、各々の開発者は、1 つの Git リポジトリではなく、非公開のローカルリポジトリと公開されたサーバーサイドリポジトリという 2 つの Git リポジトリを保有することになります。フォーク型ワークフローは、パブリックオープンソースプロジェクトで最もよく見られます。

フォーク型ワークフローの主な利点は、全員が 1 つの中央リポジトリにプッシュしなくてもコントリビューションを統合できることです。開発者は独自のサーバーサイドリポジトリにプッシュし、プロジェクトメンテナーだけが公式リポジトリにプッシュできます。これにより、メンテナーは公式なコードベースへの書き込みアクセス権を与えることなく、どの開発者からのコミットも受け入れることができます。

フォーク型ワークフローは通常、Gitflow ワークフローに基づくブランチモデルに従います。つまり、完全なフィーチャーブランチは、元のプロジェクトメンテナーのリポジトリへのマージを目的とします。その結果、このワークフローは大規模で組織的な開発チーム (信頼性の低いサードパーティーが含まれる場合も含みます) 向けの、安全なコラボレーションが可能でかつ柔軟な分散型ワークフローとなります。またこれは、オープンソースプロジェクトにおいても理想的なワークフローです。

仕組み

他の Git ワークフローと同様に、フォーク型ワークフローもサーバー上に公式の公開リポジトリを作成することから始まります。ただし、開発者は、プロジェクトで作業を開始したい場合、公式リポジトリを直接クローンすることはできません。

代わりに、公式リポジトリをフォークして、サーバー上にそのコピーを作成します。この新しいコピーは個人の公開リポジトリとして機能します。他の開発者はこのリポジトリにプッシュすることはできませんが、そこから変更を引き出すことはできます (なぜこれが重要なのかは後でわかります)。サーバーサイドのコピーを作成したら、開発者は git clone を実行してそのコピーをローカルマシンに取得します。これは、他のワークフローと同様、プライベート開発環境として機能します。

ローカルなコミットが公開可能となった場合、まずそれを公式リポジトリではなく、各々の公開リポジトリにプッシュします。次に公式リポジトリへのプルリクエストを送り、変更内容を統合する準備が整ったことをプロジェクトメンテナーに通知します。プルリクエストはまた、作業成果のコードに問題があった場合にそれに関する議論を行う便利な手段ともなります。このワークフローのステップバイステップの例を次に示します。

開発者は「公式」のサーバーサイドリポジトリを「フォーク」します。これにより、独自のサーバーサイドのコピーが作成されます。
新しいサーバーサイドのコピーは、ローカルシステムにクローンされます。
「公式」リポジトリの Git リモートパスがローカルクローンに追加されます。
新しいローカルフィーチャーブランチが作成されます。
開発者は新しいブランチに変更を加えます。
変更に対して新しいコミットが作成されます。
ブランチは開発者独自のサーバーサイドのコピーにプッシュされます。
開発者は新しいブランチから「公式」リポジトリへのプルリクエストをオープンします。
プルリクエストはマージが承認され、元のサーバーサイドリポジトリにマージされます。

フィーチャーを公式コードベースに統合するに当たっては、メンテナーはまず開発者の変更内容をメンテナーのローカルリポジトリにプルし、それがプロジェクトに問題を起こさないことを確認し、それをメンテナーのローカル main ブランチにマージし、続いてそのローカルな main ブランチをサーバー上の公式リポジトリにプッシュします。こうしてその開発者の作業成果はプロジェクトに取り込まれ、他の開発者は各々のローカルリポジトリを公式リポジトリと同期するために公式リポジトリからプルします。

フォーク型ワークフローにおける「公式」リポジトリという表現は単なる習慣であることを理解してください。公式リポジトリを「公式」と呼ぶのは単にそれがプロジェクトメンテナーの公開リポジトリだからです。

フォークとクローニング

「フォーク」されたリポジトリと「フォーク」は特別な操作ではないことに注意することが重要です。フォークされたリポジトリは、標準の git clone コマンドを使用して作成されます。フォークされたリポジトリは通常、「サーバーサイドのクローン」であり、通常は Bitbucket などのサードパーティの Git サービスによって管理およびホストされます。フォークされたリポジトリを作成する一意の Git コマンドはありません。クローン操作は、基本的にはリポジトリとその履歴のコピーです。

フォーク型ワークフローにおけるブランチ

これらの個人の公開リポジトリはすべて、他の開発者とブランチを共有するための便利な方法に過ぎません。フィーチャーブランチワークフローや Gitflow ワークフローの場合と同様、各個人は依然として個々のフィーチャーを分離するためにブランチを利用する必要があります。唯一の違いは、ブランチの共有方法にあります。フォーク型ワークフローの場合、ブランチは他の開発者のローカルリポジトリにプルされますが、フィーチャーブランチワークフローや Gitflow ワークフローの場合、ブランチは公式リポジトリにプッシュされます。

リポジトリをフォークする

フォーク型ワークフロープロジェクトの新規開発者は全員、公式リポジトリをフォークする必要があります。前述のとおり、フォークは標準的な git clone 操作に過ぎません。これは、SSH でサーバーに接続し、git clone を実行してサーバー上の別の場所にコピーすることで実現できます。Bitbucket などの人気の Git ホスティングサービスでは、このステップを自動化するリポジトリフォーク機能が提供されています。

フォークをクローンする

次に、各開発者は独自のパブリックフォークされたリポジトリをクローンする必要があります。おなじみの git clone コマンドでこれを行うことができます。

Bitbucket を使用してこれらのリポジトリをホストしていると仮定すると、プロジェクトの開発者は、独自の Bitbucket アカウントを入手し、フォークしたリポジトリのコピーを次のようにクローンする必要があります。

git clone https://user@bitbucket.org/user/repo.git

リモートの追加

他の Git ワークフローでは中央リポジトリをポイントする単一の origin リモートリポジトリを使用するのに対し、フォーク型ワークフローでは 2 種類のリモートリポジトリが必要であり、1 つは公式リポジトリ、もう 1 つは開発者個人のサーバーサイドリポジトリです。これらのリモートリポジトリには任意の名前をつけることができますが、フォークしたリモートリポジトリ (これは git clone を実行した場合に自動的に生成されます) として origin を使用し、公式リポジトリとして upstream を使用するのが一般的な習慣です。

git remote add upstream https://bitbucket.org/maintainer/repo

各々の開発者は上記のコマンドを使用して upstream へのリモート接続を自分で作成しなければなりません。この方法により、公式プロジェクトの進行に伴って、ローカルリポジトリを簡単に最新のものに維持することができます。なお、upstream リポジトリが認証を必要とする場合は (即ちオープンソースではない場合は)、次のようにユーザー名を付加する必要があります:

git remote add upstream https://user@bitbucket.org/maintainer/repo.git

このコマンドを実行すると、公式リポジトリのクローンやプルを行ったときに有効なパスワードの入力を求められます。

ブランチでの作業: 変更の実行およびプッシュ

開発者がフォークしたリポジトリのローカルコピーでは、他の Git ワークフローの場合と同様に、コードの編集、変更のコミット、ブランチの作成を行うことができます。

 git checkout -b some-feature # いくつかのコードの編集 git commit -a -m "Add first draft of some feature"

変更はすべて、公開リポジトリにプッシュされるまで完全に非公開になります。また、公式プロジェクトに進行があった場合は、git pull を使用して公開リポジトリに対して新たに行われたコミットにアクセスできます:

 git pull upstream main

各々の開発者は専用のフィーチャーブランチ上で作業をしているはずなのて、これは通常、早送りマージになります。

プルリクエストを実行する

開発者が新機能を共有する準備ができたら、2 つの作業を行う必要があります。第一は、作業成果をそれぞれの公開リポジトリにプッシュして他の開発者がそれにアクセスできるようにすることです。それぞれの origin リモートが既に作成されているので、次のコマンドを使用してこれを実行できます:

git push origin feature-branch

ここで origin リモートが、メインのコードベースではなく、各々の開発者の個人サーバーサイドリポジトリをポイントする点が他のワークフローと大きく異なる点です。

第二は、フィーチャーを公式リポジトリにマージしたい旨、プロジェクトメンテナーに通知することです。Bitbucket には「プルリクエスト」ボタンが用意されていて、それをクリックすると公式リポジトリにマージするブランチを指定するフォームが表示されます。通常、フィーチャー ブランチをマージする先は upstream リモートの main ブランチです。

概要

要点をまとめると、フォーク型ワークフローはパブリックオープンソースプロジェクトで一般的に使用されています。フォークとは、プロジェクトリポジトリのサーバーコピーで実行される git clone 操作です。フォーク型ワークフローは、Bitbucket のような Git ホスティングサービスと組み合わせて使用されることがよくあります。フォーク型ワークフローのハイレベルな例を以下に示します:

bitbucket.org/userA/open-project でホストされているオープンソースライブラリに貢献したいとします。
Bitbucket を使用して、bitbucket.org/YourName/open-project へのリポジトリのフォークを作成します。
ローカルシステムで https://bitbucket.org/YourName/open-project で git clone を実行して、リポジトリのローカルコピーを取得します。
ローカルリポジトリに新しいフィーチャー ブランチを作成します。
新機能を完成させる作業が完了し、変更を保存するために git commit が実行されます。
次に、新しいフィーチャー ブランチをリモートのフォークリポジトリにプッシュします。
Bitbucket を使用して、bitbucket.org/userA/open-project で元のリポジトリに対して新しいブランチのプルリクエストを開きます。

フォーク型ワークフローは、プロジェクトのメンテナーが、個々の貢献者の認証設定を手動で管理しなくても、任意の開発者からの貢献にリポジトリを開放するのに役立ちます。これにより、メンテナーは「プル」スタイルのワークフローをより一層引き出すことができます。オープンソースプロジェクトで最も一般的に使用されるフォーク型ワークフローを非公開のビジネスワークフローにも適用することで、リリースへのマージ対象をより信頼できる方法で制御できます。これは、Deploy Manager や厳密なリリースサイクルがあるチームで役立ちます。

どのワークフローが自分に適しているかわからない場合は、Git ワークフローの包括的な比較ページをご覧ください。