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

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

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

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

たとえば、ジョンとジェシカが同時に作業を開始するとします。ジョンは変更を完了し、それをサーバーにプッシュします。次に、ジェシカは変更をプッシュしようとしますが、サーバーはそれらを拒否します。彼女は、非高速フォワード変更をプッシュしようとしており、フェッチしてマージするまでそれができないと言われます。多くの人が慣れ親しみ、快適に使用できるパラダイムであるため、このワークフローは多くの人にとって魅力的です。

これは小規模チームに限ったことではありません。Gitのブランチモデルを使用すると、数百人の開発者が数十のブランチを介して単一のプロジェクトで同時に正常に作業できます。

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

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

これは、複数のリポジトリワークフローのバリエーションです。通常、数百人の共同作業者がいる大規模なプロジェクトで使用されます。有名な例の1つは、Linuxカーネルです。さまざまな統合マネージャーがリポジトリの特定の部分を担当しており、彼らは副官と呼ばれています。すべての副官には、慈悲深い独裁者として知られる1人の統合マネージャーがいます。慈悲深い独裁者は、自分のディレクトリから、すべての共同作業者がプルする必要がある参照リポジトリにプッシュします。プロセスは次のようになります（慈悲深い独裁者ワークフローを参照）。

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

これらは、Gitのような分散システムで可能な一般的に使用されるワークフローの一部ですが、特定の現実世界のワークフローに合わせて多くのバリエーションが可能であることがわかります。どのワークフローの組み合わせが自分に適しているかを（うまくいけば）判断できるようになったので、さまざまなフローを構成する主な役割を達成する方法について、さらに具体的な例を見ていきます。次のセクションでは、プロジェクトへの貢献に関するいくつかの一般的なパターンについて学びます。