多くの人が分散バージョン管理について読んで、それがオープンソース開発にとって良いことである理由を暗黙のうちに理解しているようです。多くの分散開発者はすべて独立して、管理者からの委任ではなく、独自の選択に従って行動します。しかし、この印象から、多くの人々は、DVCSはオープンソース環境でのみ有用であるという考えを形成しています。彼らは、プロプライエタリ製品をリリースし、そのバージョン管理システムを外部からアクセス可能にしない組織にどのように役立つか、または単一の開発者にどのように役立つかを理解できません。
CVSやSubversionなどの集中型バージョン管理の代わりに、git、darcs、Mercurialなどの分散型バージョン管理を使用することを選択した場合、企業はどのようなメリットを享受できますか？
私はVonCに同意しますが、（少なくともgitでは）新しいブランチを作成して、リポジトリの他のユーザーと必ずしも共有したくない実験的なコードやプロトタイプで簡単に作業できるようにするのは簡単です。これにより、中央リポジトリをクリーンに保つことができ（使用する場合）、開発者は、実験的なコードを中央リポジトリに配置するリスクがあるシステムでは、他の方法では試行できないことを自由に試すことができると思います。
また、ブランチ間のスワッピングが迅速であり、別々のディレクトリで一度に複数のブランチをチェックアウトする必要がないため、gitを使用して複数のブランチで作業する方がはるかに生産的であることに気付きました。
まず第一に、DVCS は集中化されたコード管理を妨げるものではありません。1 つのリポジトリを「参照」リポジトリとして設定し、すべての開発者がそこから引っ張ることができます。
したがって、ここでの利点 (実際には副作用) は、中央のコード ベースを維持しながら、データ レプリケーションによる自然なバックアップです。
しかし、真の利点は、プロジェクト間のクロス開発から得られます。つまり、「他のチームから、他のプロジェクトから」開発が必要な場合、作業を進めるために、作業ブランチを簡単にプルすることができます。中央リポジトリで公式に公開されるのを待つ必要はありません。
つまり、レポジトリが社内(企業内) にのみ複製されている場合でも、DVCS の主な利点、つまりローカルおよび多様なレポジトリからのブランチの追跡、プル、およびマージが容易であると同時に、コードを公開するためのメイン ベースが得られることを意味します。開発ライフサイクルの残りの部分。
(すべての統合、承認、本番前のテストは、その中央リポジトリに公開されたコードからのみ実行されます)。
そのように管理された DVCS を使用すると、自然な「クリーニング」プロセス (「有効な」もののみ (たとえば、少なくともユニット テスト済み) が中央リポジトリに公開される) と、よりクリーンな履歴 (すべての中間コミット) を確認できます。ローカル リポジトリのトピック ブランチにとどまることができます)。
git には、従来の中央リポジトリ ベースのシステムへの多くの架け橋があります。
たとえば、gitはsvn自体よりもsvnの優れたクライアントであることがわかりました。そのため、会社が中央リポジトリ システムの使用を主張している場合でも、中央リポジトリを維持しながら、git の個人的な利点を得ることができます。
Mercurial を使用して気づいたことの 1 つは、ワークステーションでローカルに作業する場合でも、作業方法が変わったことです。すべてのコピーが完全なスタンドアロンのリポジトリであるという考えは、異なる作業で異なるコピーを保持し、それらを一緒にマージするか、「共通の」リポジトリにマージするのに役立ちます。さまざまなもののパッチ セットがまとめられているだけでなく、作業自体が分離されているため、これは素晴らしいことです。これらのことは、従来のシステムでは何らかの方法で実行できますが、Mercurial では当然のことです。ワークフローを整理する際の柔軟性を高めることには、他にもメリットがあります。
ここで利点を確認してください...
http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git
http://www.ehow.com/info_12217814_git-commit-vs-push.html