5.1 分散Git - 分散ワークフロー

集中型システムでは、通常、単一のコラボレーションモデル、つまり集中型ワークフローが存在します。1つの中央ハブ、または*リポジトリ*がコードを受け入れ、全員がそのリポジトリと作業を同期します。多くの開発者は、そのハブのコンシューマーであるノードであり、その集中型の場所と同期します。

これは、2人の開発者がハブからクローンし、両方が変更を加えた場合、最初に変更をプッシュバックする開発者は問題なく行えます。2番目の開発者は、最初の開発者の変更を上書きしないように、変更をプッシュアップする前に最初の開発者の作業をマージする必要があります。この概念は、GitでもSubversion (または任意のCVCS) と同じであり、このモデルはGitでも完璧に機能します。

会社やチームで集中型ワークフローにすでに慣れている場合は、Gitでそのワークフローを簡単に継続して使用できます。単一のリポジトリを設定し、チームの全員にプッシュアクセスを与えるだけです。Gitは、ユーザーが互いの変更を上書きすることを許可しません。

ジョンとジェシカが同時に作業を開始するとします。ジョンは変更を完了し、サーバーにプッシュします。次に、ジェシカは変更をプッシュしようとしますが、サーバーはそれらを拒否します。彼女は、ノン・ファスト・フォワードの変更をプッシュしようとしていること、そしてフェッチしてマージするまでそうできないことを告げられます。このワークフローは、多くの人が慣れ親しんだパラダイムであるため、多くの人にとって魅力的です。

これは小規模なチームに限ったことではありません。Gitのブランチモデルでは、何百もの開発者が同時に数十のブランチを通じて単一のプロジェクトにうまく取り組むことが可能です。

Gitでは複数のリモートリポジトリを持つことができるため、各開発者が自分の公開リポジトリへの書き込みアクセスと、他のすべての人のリポジトリへの読み取りアクセスを持つワークフローが可能になります。このシナリオには、多くの場合、「公式」プロジェクトを表す標準リポジトリが含まれます。そのプロジェクトに貢献するには、プロジェクトの独自の公開クローンを作成し、変更をそこにプッシュします。次に、メインプロジェクトのメンテナーに、変更をプルインするようにリクエストを送信できます。メンテナーは、あなたのリポジトリをリモートとして追加し、変更をローカルでテストし、ブランチにマージし、自分のリポジトリにプッシュバックできます。このプロセスは次のように機能します (「インテグレーションマネージャーワークフロー」を参照)。

これは、GitHubやGitLabのようなハブベースのツールで非常によく使われるワークフローで、プロジェクトをフォークし、フォークしたリポジトリに変更をプッシュして誰でも見られるようにするのが簡単です。このアプローチの主な利点の1つは、作業を継続でき、メインリポジトリのメンテナーがいつでも変更をプルインできることです。貢献者は、プロジェクトが変更を取り込むのを待つ必要がなく、各当事者が自分のペースで作業できます。

これは、複数リポジトリワークフローのバリエーションです。通常、何百人ものコラボレーターが参加する巨大なプロジェクトで使用されます。有名な例の1つはLinuxカーネルです。さまざまなインテグレーションマネージャーがリポジトリの特定の部分を担当しており、彼らは*副官*と呼ばれます。すべての副官には、慈善的な独裁者として知られる1人のインテグレーションマネージャーがいます。慈善的な独裁者は、自分のディレクトリから、すべてのコラボレーターがプルする必要がある参照リポジトリにプッシュします。このプロセスは次のように機能します (「慈善的な独裁者ワークフロー」を参照)。

このようなワークフローは一般的ではありませんが、非常に大規模なプロジェクトや、階層の深い環境で役立ちます。これにより、プロジェクトリーダー (独裁者) は作業の多くを委任し、統合する前にコードの大きなサブセットを複数のポイントで収集できます。

これらはGitのような分散システムで可能な一般的なワークフローの一部ですが、特定の実際のワークフローに合わせてさまざまなバリエーションが可能であることがわかります。これで、どのワークフローの組み合わせが自分に適しているかを (願わくば) 判断できるようになったので、異なるフローを構成する主要な役割をどのように達成するかについて、より具体的な例をいくつか説明します。次のセクションでは、プロジェクトに貢献するためのいくつかの一般的なパターンについて学びます。