分散バージョン管理

ソフトウェア開発において、分散バージョン管理（分散リビジョン管理とも呼ばれる）は、完全なコードベース（その完全な履歴を含む）がすべての開発者のコ​​ンピュータにミラーリングされるバージョン管理の形式です。 ^[1]集中型バージョン管理と比較して、これにより、自動管理ブランチとマージが可能になり、ほとんどの操作（プッシュとプルを除く）が高速化され、オフラインで作業する機能が向上し、バックアップに単一の場所に依存しなくなります。^{[1] [2] [3]}世界で最も人気のあるバージョン管理システムであるGit ^[4]は、分散型バージョン管理システムです。

2010年、ソフトウェア開発の著者であるジョエル・スポルスキーは、分散バージョン管理システムを「おそらく[過去]10年間のソフトウェア開発技術における最大の進歩」と評した。^[2]

分散バージョン管理システム (DVCS) は、集中型システムのクライアント サーバーアプローチとは対照的に、バージョン管理にピアツーピア アプローチを使用します。分散リビジョン管理は、ピアツーピアでパッチを転送することでリポジトリを同期します。コードベースの単一の中央バージョンは存在せず、代わりに各ユーザーが作業コピーと完全な変更履歴を持ちます。

DVCS の利点 (集中型システムと比較した場合) は次のとおりです。

• ユーザーがネットワークに接続していないときでも生産的に作業できるようにします。
• DVCSでは、中央サーバーと通信する必要がないため、一般的な操作（コミット、履歴の表示、変更の元に戻すなど）が高速になります。^[5] DVCSでは、他のピア間で変更を共有する場合にのみ通信が必要です。
• 非公開作業を許可しているため、ユーザーは公開したくない初期の草稿でも変更を加えることができます。^{[引用が必要]}
• 作業コピーはリモートバックアップとして効果的に機能し、1台の物理マシンを単一障害点として依存することを回避します。^[5]
• 開発ブランチや司令官/中尉モデルの使用など、さまざまな開発モデルを使用できます。 ^[6]
• プロジェクトの「リリースバージョン」の集中管理を可能にする^{[引用が必要]}
• FOSSソフトウェア プロジェクトでは、リーダーシップの対立や設計上の意見の不一致により行き詰まっているプロジェクトからプロジェクト フォークを作成する方がはるかに簡単です。

DVCS の欠点 (集中型システムと比較した場合) は次のとおりです。

• リポジトリの初期チェックアウトは、すべてのブランチとリビジョン履歴がデフォルトでローカル マシンにコピーされるため、集中型バージョン管理システムでのチェックアウトに比べて遅くなります。
• ほとんどの集中型 VCS の一部であるロック メカニズムの欠如は、グラフィック アセットや複雑すぎる単一ファイルのバイナリまたは XML パッケージ (例: Office ドキュメント、PowerBI ファイル、SQL Server Data Tools BI パッケージなど) などのマージ不可能なバイナリ ファイルに関しては依然として重要な役割を果たします。^{[引用が必要]}
• すべてのユーザーがコードベースの完全な履歴のコピーを保持するには、追加のストレージが必要です。^[7]
• すべての参加者がローカルに脆弱なコピーを持つため、コードベースの露出度が高まります。^{[引用が必要]}

もともと集中型だったシステムの一部は、現在では分散型機能を提供しています。Team Foundation Serverと Visual Studio Team Services は、Git ホスティングを介して集中型および分散型のバージョン管理リポジトリをホストするようになりました。

同様に、一部の分散システムでは、チェックアウト時間とストレージコストの問題を軽減する機能が提供されるようになりました。たとえば、Microsoftが大規模なコードベースで動作するように開発したGit用の仮想ファイルシステム^[8]では、必要な場合にのみファイルをローカルストレージにダウンロードする仮想ファイルシステムが公開されています。

分散モデルは、Linuxカーネルプロジェクトなど、部分的に独立した開発者がいる大規模プロジェクトに適しています。開発者は独立して作業し、変更をマージ（または拒否）のために提出できるためです。この柔軟性により、最も広く使用されているインテグレーターワークフローなどのカスタムソースコード貢献ワークフローを採​​用できます。開発者が異なるバージョンの問題を回避するために作業をシリアル化する必要がある集中型モデルとは異なり、分散モデルでは、開発者はコードの履歴全体をローカルマシンに複製できます。最初にローカルリポジトリに変更をコミットして「変更セット」を作成し、その後マスターリポジトリにプッシュします。このアプローチにより、開発者はローカルで切断された状態で作業できるため、分散チームにとって便利です。^[9]

Linuxなどの真の分散プロジェクトでは、各貢献者がプロジェクトの独自のバージョンを維持し、異なる貢献者がそれぞれのバージョンをホストし、必要に応じて他のユーザーからの変更をプルすることで、複数の異なるノードから一般的なコンセンサスが生まれます。これにより、「フォーク」のプロセスも簡単になります。必要なのは、1 人の貢献者が他の貢献者からのプル リクエストの受け入れを停止し、コードベースが徐々に離れていくようにすることだけです。

ただし、この仕組みを維持するのは困難な場合があり、その結果、多くのプロジェクトは、1 人の貢献者が普遍的な「上流」、つまりほぼ常に変更がプルされるリポジトリになるパラダイムに移行することを選択します。このパラダイムでは、すべてのプロジェクトに、非公式に公式リポジトリと見なされ、プロジェクトのメンテナーによって共同で管理される中央リポジトリがあるため、開発はある程度集中化されます。分散バージョン コントロール システムでは、新しい開発者が他の貢献者のリポジトリのコピーを「複製」することが容易ですが、中央モデルでは、新しい開発者は常に中央リポジトリを複製して、コード ベースの同一のローカル コピーを作成します。このシステムでは、中央リポジトリのコード変更は定期的にローカル リポジトリと同期され、開発が完了すると、変更はできるだけ早く中央リポジトリに統合されます。

この集中化パターンを利用する組織は、多くの場合、中央リポジトリをGitHubなどのサードパーティ サービスでホストすることを選択します。これにより、自己ホスト型リポジトリよりも信頼性の高い稼働時間が提供されるだけでなく、問題追跡や継続的インテグレーションなどの集中機能も追加できます。

分散バージョン管理システムを使用するソースコードリポジトリへの貢献は、通常、プルリクエスト（マージリクエストとも呼ばれる）によって行われます。^[10]貢献者は、プロジェクトのメンテナーにソースコードの変更をプルするように要求します。これが「プルリクエスト」という名前です。貢献がソースベースの一部になる必要がある場合、メンテナーはプルリクエストをマージする必要があります。 ^[11]

開発者はプルリクエストを作成してメンテナーに新しい変更を通知します。各プルリクエストにはコメントスレッドが関連付けられます。これにより、コードの変更について集中的に議論することができます。送信されたプルリクエストは、リポジトリにアクセスできるすべてのユーザーに表示されます。プルリクエストはメンテナーによって承認または拒否されます。^[12]

プルリクエストがレビューされ承認されると、リポジトリにマージされます。確立されたワークフローによっては、公式リリースに含める前にコードをテストする必要がある場合があります。そのため、一部のプロジェクトでは、テストされていないプルリクエストをマージするための特別なブランチが含まれています。^{[11] [13]他のプロジェクトでは、}継続的インテグレーションツールを使用して、すべてのプルリクエストに対して自動テストスイートを実行し、レビュー担当者が新しいコードに適切なテストカバレッジがあるかどうかを確認します。

最初のオープンソース DVCS システムには、Arch、Monotone、Darcs などがありました。ただし、オープンソース DVCS は、 GitとMercurialがリリースされるまではあまり人気がありませんでした。

BitKeeperは2002年から2005年にかけてLinuxカーネルの開発に使用されました。^[14]現在世界で最も人気のあるバージョン管理システムであるGitの開発^[4]は、 BitKeeperを開発した会社が、Linus Torvalds氏や他のLinuxカーネル開発者が以前に利用していた無料ライセンスを取り消すという決定をきっかけに始まりました。^[14]

• さまざまなリビジョン管理システムに関するエッセイ、特に「集中型 SCM と分散型 SCM」のセクション
• 分散バージョン管理システムの紹介 - IBM Developer Works の記事