フォーク型ワークフロー
フォーク型ワークフローは、他の一般的な Git ワークフローとは根本的に異なります。「中央」コードベースとして機能する単一のサーバーサイド リポジトリを使うのではなく、各々の開発者に独自のサーバーサイド リポジトリを割り当てます。つまり、各々の開発者は、1 つの Git リポジトリではなく、非公開のローカル リポジトリと公開されたサーバーサイド リポジトリという 2 つの Git リポジトリを保有することになります。フォーク型ワークフローは、パブリック オープン ソース プロジェクトで最もよく見られます。
フォーク型ワークフローの主な利点は、全員が 1 つの中央リポジトリにプッシュしなくてもコントリビューションを統合できることです。開発者は独自のサーバーサイド リポジトリにプッシュし、プロジェクト メンテナーだけが公式リポジトリにプッシュできます。これにより、メンテナーは公式なコードベースへの書き込みアクセス権を与えることなく、どの開発者からのコミットも受け入れることができます。
フォーク型ワークフローは通常、Gitflow ワークフローに基づくブランチ・モデルに従います。つまり、完全なフィーチャー・ブランチは、元のプロジェクト・メンテナーのリポジトリへのマージを目的とします。その結果、このワークフローは大規模で組織的な開発チーム（信頼性の低いサードパーティーが含まれる場合も含みます）向けの、安全なコラボレーションが可能でかつ柔軟な分散型ワークフローとなります。またこれは、オープン・ソース・プロジェクトにおいても理想的なワークフローです。
仕組み
他の Git ワークフローと同様に、フォーク型ワークフローもサーバー上に公式の公開リポジトリを作成することから始まります。ただし、開発者は、プロジェクトで作業を開始したい場合、公式リポジトリを直接クローンすることはできません。
代わりに、公式リポジトリをフォークして、サーバー上にそのコピーを作成します。この新しいコピーは個人の公開リポジトリとして機能します。他の開発者はこのリポジトリにプッシュすることはできませんが、そこから変更を引き出すことはできます（なぜこれが重要なのかは後でわかります）。サーバーサイドのコピーを作成したら、開発者は git clone を実行してそのコピーをローカル・マシンに取得します。これは、他のワークフローと同様、プライベート開発環境として機能します。
ローカルなコミットが公開可能となった場合、まずそれを公式リポジトリではなく、各々の公開リポジトリにプッシュします。次に公式リポジトリへのプル リクエストを送り、変更内容を統合する準備が整ったことをプロジェクト メンテナーに通知します。プル リクエストはまた、作業成果のコードに問題があった場合にそれに関する議論を行う便利な手段ともなります。このワークフローのステップ バイ ステップの例を次に示します。
関連資料
高度な Git ログ
ソリューションを見る
Bitbucket Cloud での Git の使用方法についてのチュートリアルです。
1. 開発者は「公式」のサーバーサイド リポジトリを「フォーク」します。これにより、独自のサーバーサイドのコピーが作成されます。
2. 新しいサーバーサイドのコピーは、ローカル・システムにクローンされます。
3. 「公式」リポジトリの Git リモート・パスがローカル・クローンに追加されます。
4. 新しいローカル・フィーチャー・ブランチが作成されます。
5. 開発者は新しいブランチに変更を加えます。
6. 変更に対して新しいコミットが作成されます。
7. ブランチは開発者独自のサーバーサイドのコピーにプッシュされます。
8. 開発者は新しいブランチから「公式」リポジトリへのプル・リクエストをオープンします。
9. プル・リクエストはマージが承認され、元のサーバーサイド・リポジトリにマージされます。
フィーチャーを公式コードベースに統合するに当たっては、メンテナーはまず開発者の変更内容をメンテナーのローカル リポジトリにプルし、それがプロジェクトに問題を起こさないことを確認し、それをメンテナーのローカル main ブランチにマージし、続いてそのローカルな main ブランチをサーバー上の公式リポジトリにプッシュします。こうしてその開発者の作業成果はプロジェクトに取り込まれ、他の開発者は各々のローカル リポジトリを公式リポジトリと同期するために公式リポジトリからプルします。
フォーク型ワークフローにおける「公式」リポジトリという表現は単なる習慣であることを理解してください。公式リポジトリを「公式」と呼ぶのは単にそれがプロジェクトメンテナーの公開リポジトリだからです。
フォークとクローニング
フォーク型ワークフローにおけるブランチ
これらの個人の公開リポジトリはすべて、他の開発者とブランチを共有するための便利な方法に過ぎません。フィーチャー ブランチ ワークフローや Gitflow ワークフローの場合と同様、各個人は依然として個々のフィーチャーを分離するためにブランチを利用する必要があります。唯一の違いは、ブランチの共有方法にあります。フォーク型ワークフローの場合、ブランチは他の開発者のローカル リポジトリにプルされますが、フィーチャー ブランチ ワークフローや Gitflow ワークフローの場合、ブランチは公式リポジトリにプッシュされます。
リポジトリをフォークする
フォーク型ワークフロー プロジェクトの新規開発者は全員、公式リポジトリをフォークする必要があります。前述のとおり、フォークは標準的な git clone 操作に過ぎません。これは、SSH でサーバーに接続し、git clone を実行してサーバー上の別の場所にコピーすることで実現できます。Bitbucket などの人気の Git ホスティング サービスでは、このステップを自動化するリポジトリ フォーク機能が提供されています。
フォークをクローンする
フォーク型ワークフロー プロジェクトの新規開発者は全員、公式リポジトリをフォークする必要があります。前述のとおり、フォークは標準的な git clone 操作に過ぎません。これは、SSH でサーバーに接続し、git clone を実行してサーバー上の別の場所にコピーすることで実現できます。Bitbucket などの人気の Git ホスティング サービスでは、このステップを自動化するリポジトリ フォーク機能が提供されています。
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 # Edit some code 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 ホスティング サービスと組み合わせて使用されることがよくあります。フォーク型ワークフローのハイレベルな例を以下に示します:
1. bitbucket.org/userA/open-project でホストされているオープン ソース ライブラリに貢献したいとします。
2. Bitbucket を使用して、bitbucket.org/YourName/open-project へのリポジトリのフォークを作成します。
3. ローカル・システムで https://bitbucket.org/YourName/open-project で git clone を実行して、リポジトリのローカル・コピーを取得します。
4. ローカル・リポジトリに新しいフィーチャー・ブランチを作成します。
5. 新機能を完成させる作業が完了し、変更を保存するために git commit が実行されます。
6.次に、新しいフィーチャー ブランチをリモートのフォーク リポジトリにプッシュします。
7. Bitbucket を使用して、bitbucket.org/userA/open-project で元のリポジトリに対して新しいブランチのプル・リクエストを開きます。
フォーク型ワークフローは、プロジェクトのメンテナーが、個々の貢献者の認証設定を手動で管理しなくても、任意の開発者からの貢献にリポジトリを開放するのに役立ちます。これにより、メンテナーは「プル」スタイルのワークフローをより一層引き出すことができます。オープン ソース プロジェクトで最も一般的に使用されるフォーク型ワークフローを非公開のビジネス ワークフローにも適用することで、リリースへのマージ対象をより信頼できる方法で制御できます。これは、Deploy Manager や厳密なリリースサイクルがあるチームで役立ちます。
どのワークフローが自分に適しているかわからない場合は、Git ワークフローの包括的な比較ページをご覧ください。
この記事を共有する
次のトピック
おすすめコンテンツ
次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。
Bitbucket ブログ
DevOps ラーニング パス
