実際には、開発者は互いのローカル リポジトリ間でプッシュおよびプルするよりも、中央リポジトリを使用することを好むことがわかると思います。中央リポジトリのクローンを作成したら、追跡ブランチで作業している間、フェッチとプッシュは簡単なコマンドです。同僚全員のローカル リポジトリに半ダースのリモートを追加するのは面倒であり、これらのリポジトリに常にアクセスできるとは限りません (電源がオフになっている、自宅に持ち帰ったラップトップなど)。
ある時点で、全員が同じプロジェクトに取り組んでいる場合、すべての作業を統合する必要があります。これは、すべての変更がまとめられる統合ブランチが必要であることを意味します。これは当然、すべての開発者がアクセスできる場所である必要があります。たとえば、主任開発者のラップトップには属しません。
中央リポジトリをセットアップしたら、cvs/svn スタイルのワークフローを使用してチェックインと更新を行うことができます。cvs update は、ローカルに変更がある場合は git fetch and rebase になり、そうでない場合は単に git pull になります。cvs commit は git commit と git push になります。
このセットアップでは、完全に集中化された VCS システムと同様の立場になります。開発者が変更を送信 (git push) すると、チームの他のメンバーに表示されるようにする必要があります。変更は中央サーバーにあり、バックアップされます。
どちらの場合も規律が必要なのは、開発者が長期にわたって実行中の変更を中央リポジトリの外に保持しないようにすることです。私たちのほとんどは、ある開発者が機能「x」に取り組んでいて、コア コードの根本的な変更が必要な状況で働いたことがあるでしょう。この変更により、他のすべての人が完全に再構築する必要がありますが、機能はまだメインストリームの準備ができていないため、適切な時点までチェックアウトしたままにします.
状況は両方の状況で非常に似ていますが、実際にはいくつかの違いがあります。git を使用すると、ローカル コミットを実行し、ローカル履歴を管理できるため、個々の開発者は cvs のようなものほど中央リポジトリにプッシュする必要性を感じない場合があります。
一方、ローカルコミットの使用は利点として使用できます。すべてのローカル コミットを中央リポジトリの安全な場所にプッシュすることは、それほど難しくありません。ローカル ブランチは、開発者固有のタグ名前空間に格納できます。
たとえば、Joe Bloggs の場合、ローカル リポジトリにエイリアスを作成して、 (eg) に応答して次のような処理を実行できますgit mybackup。
git push origin +refs/heads/*:refs/jbloggs/*
これは、すべてのローカル変更が安全にバックアップされていることを確認するために、任意の時点 (1 日の終わりなど) に使用できる単一のコマンドです。
これは、あらゆる種類の災害に役立ちます。Joe のマシンが故障し、彼は別のマシンを使用してコミットを保存し、中断したところから続行することができます。ジョーは病気？Fred は、Joe のブランチをフェッチして、昨日行ったが master に対してテストする機会がなかった「必要な」修正を取得できます。
元の質問に戻ります。dVCS と集中型 VCS を区別する必要はありますか? あなたは、dVCS の場合、半分実装された機能とバグ修正が中央リポジトリに配置されることはないと言いますが、私は違いがある必要はないと主張します。
集中化された VCS を使用しているときに、半分実装された機能が 1 つの開発者の作業ボックスにとどまる多くのケースを見てきました。半分しか書かれていない機能をメイン ストリームにチェックインすることを許可するポリシーを採用するか、中央ブランチを作成する決定を下す必要があります。
dVCS でも同じことが起こりえますが、同じ決定を下す必要があります。重要だが未完了の作業がある場合は、一元的に保存する必要があります。git の利点は、この中央ブランチの作成がほとんど簡単なことです。