Loading article…
ソフトウェア開発において、分散バージョン管理（分散リビジョン管理とも呼ばれる）は、完全な履歴を含む完全なコードベースがすべての開発者のコンピュータにミラーリングされるバージョン管理の一形態です。 [ 1 ]中央集権型バージョン管理と比較すると、自動的なブランチ管理とマージが可能になり、ほとんどの操作（プッシュとフェッチを除く）が高速化され、オフラインでの作業能力が向上し、バックアップのために単一の場所に依存しません。[ 1 ] [ 2 ] [ 3 ]世界で最も人気のあるバージョン管理システムであるGit [ 4 ]は、分散バージョン管理システムです。
分散型バージョン管理システム（DVCS）は、集中型システムのクライアント・サーバー方式とは異なり、ピアツーピア方式でバージョン管理を行います。分散型リビジョン管理では、ピア間でパッチを転送することでリポジトリを同期します。コードベースの単一の中央バージョンは存在せず、各ユーザーが作業コピーと完全な変更履歴を保持します。
DVCSの利点（集中型システムとの比較）は以下のとおりです。
DVCSの欠点（集中型システムと比較した場合）は以下のとおりです。
従来は集中型だったシステムの中には、分散型機能を提供するものもある。Team Foundation ServerとVisual Studio Team Servicesは、Gitをホスティングすることで、集中型および分散型のバージョン管理リポジトリをホストできるようになった。
同様に、現在では一部の分散システムがチェックアウト時間とストレージコストの問題を軽減する機能を提供しています。たとえば、Microsoft が非常に大規模なコードベースを扱うために開発したGit 用仮想ファイルシステム[ 8 ]は、必要なときにのみファイルをローカルストレージにダウンロードする仮想ファイルシステムを公開します。
分散モデルは、Linuxカーネルのように部分的に独立した開発者がいる大規模プロジェクトに一般的に適しています。このモデルでは、開発者は独立したブランチで作業し、後で他の開発者がコミット、監査、マージ（または拒否）できる変更を適用できます[ 9 ] 。このモデルは柔軟性が高く、元のプロジェクトとは異なる目的を持つカスタムソースコードブランチ（フォーク）の作成と適応が可能です。さらに、開発者は既存のコードリポジトリをローカルにクローンし、ローカル環境から作業できます。ローカル環境では変更が追跡され、ローカルリポジトリにコミットされます[ 10 ]。これにより、リポジトリのマスターブランチにコミットする前に変更をより適切に追跡できます。このようなアプローチにより、開発者はローカルで接続されていないブランチで作業できるため、大規模な分散チームにとってより便利になります。
Linuxのような真に分散型のプロジェクトでは、各貢献者がそれぞれ独自のプロジェクトバージョンを管理し、異なる貢献者がそれぞれのバージョンをホストして、必要に応じて他のユーザーからの変更を取り込むことで、複数の異なるノードから共通の合意が形成されます。これにより、「フォーク」プロセスも容易になり、必要なのは、貢献者の1人が他の貢献者からのプルリクエストの受け入れを停止し、コードベースが徐々に分離していくのを待つだけです。
しかし、この方式は維持が難しいため、多くのプロジェクトでは、1人の貢献者が普遍的な「アップストリーム」、つまり変更がほぼ常にプルされるリポジトリとなるパラダイムに移行することを選択しています。このパラダイムでは、すべてのプロジェクトに中央リポジトリが設けられ、非公式には公式リポジトリとみなされ、プロジェクトのメンテナーが共同で管理するため、開発はある程度再中央集権化されます。分散型バージョン管理システムでは、新規開発者が他の貢献者のリポジトリのコピーを簡単に「クローン」できますが、中央モデルでは、新規開発者は常に中央リポジトリをクローンして、コードベースの同一のローカルコピーを作成します。このシステムでは、中央リポジトリのコード変更は定期的にローカルリポジトリと同期され、開発が完了したら、変更はできるだけ早く中央リポジトリに統合されるべきです。
この集中型パターンを採用する組織は、多くの場合、 GitHubのようなサードパーティのサービスで中央リポジトリをホストすることを選択します。これは、自社でホストするリポジトリよりも稼働率が高いだけでなく、課題追跡システムや継続的インテグレーションなどの集中型機能を追加することもできます。
分散バージョン管理システムを使用するソースコードリポジトリへの貢献は、一般的にプルリクエスト（マージリクエストとも呼ばれる）によって行われます。[ 11 ]貢献者は、プロジェクトメンテナーにソースコードの変更を取り込むよう要求します。これが「プルリクエスト」という名前の由来です。貢献がソースベースの一部となるためには、メンテナーはプルリクエストをマージする必要があります。 [ 12 ]
開発者はプルリクエストを作成して、新しい変更をメンテナーに通知します。各プルリクエストにはコメントスレッドが関連付けられています。これにより、コードの変更について集中的な議論が可能になります。送信されたプルリクエストは、リポジトリへのアクセス権を持つすべての人に表示されます。プルリクエストは、メンテナーによって承認または拒否されます。[ 13 ]
プルリクエストがレビューされ承認されると、リポジトリにマージされます。確立されたワークフローによっては、公式リリースに含める前にコードをテストする必要がある場合があります。そのため、テストされていないプルリクエストをマージするための特別なブランチを持つプロジェクトもあります。[ 12 ] [ 14 ]他のプロジェクトでは、継続的インテグレーションツールを使用してすべてのプルリクエストに対して自動テストスイートを実行し、レビュー担当者が新しいコードに適切なテストカバレッジがあることを確認します。
最初のオープンソースの分散型バージョン管理システム（DVCS）には、Arch、Monotone、Darcsなどがありました。しかし、オープンソースのDVCSは、 GitとMercurialが登場するまで、あまり普及しませんでした。
BitKeeperは2002年から2005年にかけてLinuxカーネルの開発に使用されました。[ 15 ]現在世界で最も人気のあるバージョン管理システムであるGitの開発[ 4 ]は、 BitKeeperを作成した会社が、Linus Torvaldsや他のLinuxカーネル開発者が以前利用していた無料ライセンスを取り消すという決定によって促されました。[ 15 ]