分散バージョン管理
Gitリポジトリを初期化するプロセス。Gitは、最も広く使用されている分散型バージョン管理ソフトウェアの1つです。

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

分散型と集中型

分散型バージョン管理システム（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 ] 。このモデルにより柔軟性が向上し、元のプロジェクトとは目的が異なるカスタムソースコードブランチ（フォーク）の作成と適応が可能になります。さらに、開発者は既存のコードリポジトリをローカルに複製し、変更が追跡されてローカルリポジトリにコミットされるローカル環境から作業できるため[ 10 ]、リポジトリのマスターブランチにコミットされる前に変更をより適切に追跡できます。このようなアプローチにより、開発者はローカルの切断されたブランチで作業できるため、大規模な分散チームにとって便利になります。

中央リポジトリとブランチリポジトリ

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

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

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

プルリクエスト

分散型バージョン管理システムを使用するソースコードリポジトリへの貢献は、一般的にプルリクエスト（マージリクエストとも呼ばれる）によって行われます。[ 11 ]貢献者はプロジェクトのメンテナーにソースコードの変更をプルするよう要求するため、「プルリクエスト」と呼ばれます。貢献をソースベースの一部とするには、メンテナーはプルリクエストをマージする必要があります。 [ 12 ]

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

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

歴史

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

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

参照

参考文献

  1. ^ a b Chacon, Scott; Straub, Ben (2014). 「バージョン管理について」 . Pro Git (第2版). Apress. 第1章1. 2019年6月4日閲覧。
  2. ^ Spolsky, Joel (2010年3月17日). 「分散バージョン管理は今後も続く」 Joel on Software . 2019年6月4日閲覧。
  3. ^ 「分散バージョン管理入門（図解）」www.betterexplained.com . 2018年1月7日閲覧。
  4. ^ a b「2016年のバージョン管理システムの人気」www.rhodecode.com . 2018年1月7日閲覧。
  5. ^ a b O'Sullivan, Bryan. 「Mercurialによる分散リビジョン管理」 . 2007年7月13日閲覧。
  6. ^ Chacon, Scott; Straub, Ben (2014). 「分散ワークフロー」 . Pro Git (第2版). Apress. 第5.1章.
  7. ^ 「バージョン管理とは：集中型 vs. DVCS」 www.atlassian.com 2012年2月14日. 2018年1月7日閲覧。
  8. ^ Jonathan Allen (2017年2月8日). 「Microsoftは大規模リポジトリに関するGitの問題を解決した方法」 . 2019年8月6日閲覧。
  9. ^ 「パッチの提出：コードをカーネルに組み込むための必須ガイド — Linuxカーネルドキュメント」 www.kernel.org . 2024年11月22日閲覧。
  10. ^ 「Git - リビジョン選択」 . git-scm.com . 2024年11月22日閲覧。
  11. ^シツェブランダイ、シツェ (2014 年 9 月 29 日)。「GitLab フロー」。GitLab 。2018 年8 月 4 日に取得。
  12. ^ a b Johnson, Mark (2013年11月8日). 「プルリクエストとは何か？」 Oaawatch . 2016年3月27日閲覧。
  13. ^ 「プルリクエストの使用」 . GitHub . 2016年3月27日閲覧。
  14. ^ 「プルリクエストの作成」。Atlassian 。 2016年3月27日閲覧。
  15. ^ a b McAllister, Neil. 「Linus TorvaldsのBitKeeperの大失敗」 InfoWorld . 2017年3月19日閲覧。
「 https://en.wikipedia.org/w/index.php?title=Distributed_version_control&oldid=1322881222」より取得