私はMercurialの開発者で、Mercurial のコンサルタントとして働いてきました。ですから、あなたの質問は非常に興味深いと思います。
- ローカルでコミットすることの利点または価値は何ですか? [...]
最近のIDEは、単純な元に戻す/やり直しを超えてローカルの変更を追跡できることは間違いありません。ただし、これらのファイル スナップショットと完全なバージョン管理システムの間には、まだ機能上のギャップがあります。
ローカル コミットでは、レビューのために送信する前に、ローカルで「ストーリー」を準備するオプションが提供されます。私はよく、2 ~ 5 件のコミットを伴ういくつかの変更に取り組んでいます。コミット 4 を作成した後、戻ってコミット 2 を少し修正する可能性があります (コミット 4 を作成した後にコミット 2 でエラーが発生した可能性があります)。そうすれば、最新のコードだけでなく、最後のいくつかのコミットにも取り組むことができます。すべてがローカルである場合、それは簡単に可能ですが、中央サーバーと同期する必要がある場合は、よりトリッキーになります.
- ハードドライブをクラッシュさせたらどうなりますか? [...] では、中央レポにチェックインするのと比べて、どのようにクールなのでしょうか?
全然かっこよくない!:-)
ただし、中央リポジトリを使用しても、作業コピー内のコミットされていないデータについて心配する必要があります。したがって、とにかくバックアップソリューションを用意する必要があると主張します.
私の経験では、多くの場合、コミットされていないデータの大きな塊が集中型システムの作業コピーに横たわっています。クライアントは、開発者に少なくとも週に 1 回コミットするよう説得しようとしている方法を教えてくれました。
多くの場合、次の理由により、変更がコミットされないままになります。
彼らは本当に終わっていません。コードに debug print ステートメントが含まれていたり、不完全な関数が含まれていたりする可能性があります。
コミットすることは集中型システムtrunk
では危険です。他のすべての人に影響を与えるからです。
コミットするには、最初に中央リポジトリとマージする必要があります。コードに他の競合する変更が加えられていることがわかっている場合、そのマージは威圧的かもしれません。変更がすべて完了していない可能性があり、既知の良好な状態から作業することを好むため、マージは単純に煩わしい場合があります。
過負荷の中央サーバーと通信する必要がある場合、コミットが遅くなる可能性があります。オフショアの場所にいる場合、コミットはさらに遅くなります。
上記が実際には集中型バージョン管理と分散型バージョン管理の問題ではないと思うなら、あなたは絶対に正しいです。CVCS を使用すると、人々は別々のブランチで作業できるため、上記の 2 と 3 を簡単に回避できます。別の使い捨てブランチを使用すると、より洗練された変更をコミットする別のブランチを作成できるため、好きなだけコミットすることもできます (解決 1)。ただし、コミットはまだ遅くなる可能性があるため、4 は適用できます。
DVCS を使用する人は、貧乏人のバックアップ ソリューションとして、「ローカル」コミットをリモート サーバーにプッシュすることがよくあります。チームの他のメンバーが作業しているメイン サーバーではなく、別の (場合によってはプライベートな) サーバーにプッシュします。そうすれば、彼らは分離して作業し、オフサイトのバックアップを保持できます.
ええ、私もその議論が好きではありませんでした。私は 99% の時間、良好なインターネット接続を使用しており、これが問題になるほど十分に飛行していません :-)
ただし、本当の議論は、オフラインであるということではなく、オフラインのふりをすることができるということです。より正確には、変更を中央リポジトリにすぐに送信する必要なく、分離して作業できることです。
DVCS ツールは、人々がオフラインで作業している可能性があるという考えに基づいて設計されています。これには多くの重要な結果があります。
ブランチのマージは自然なことになります。人が並行して作業できるようになると、当然コミット グラフにフォークが発生します。したがって、これらのツールはブランチのマージに非常に優れている必要があります。SVNのようなツールは、マージがあまり得意ではありません。
Git、Mercurial、およびその他の DVCS ツールは、分散されているから直接ではなく、この分野でより多くのテストを行っているため、よりよくマージされます。
より柔軟に。DVCS を使用すると、任意のリポジトリ間で変更を自由にプッシュ/プルできます。実際の中央サーバーを使用せずに、自宅と職場のコンピューター間でプッシュ/プルを行うことがよくあります。公開の準備ができたら、Bitbucket のような場所にプッシュします。
マルチサイト同期は「エンタープライズ機能」ではなく、組み込み機能です。そのため、オフショアの場所がある場合、彼らはローカル ハブ リポジトリをセットアップし、これを相互に使用できます。その後、ローカル ハブの時間、毎日、または都合の良いときに同期できます。これには、定期的に実行さhg pull
れるcronjob だけが必要です。git fetch
クライアント側のロジックが増えるため、スケーラビリティが向上します。これは、中央サーバーのメンテナンスが少なくなり、クライアント側のツールがより強力になることを意味します。
DVCS を使用すると、(コミット メッセージだけでなく)コードのリビジョンを通じてキーワード検索を実行できると期待しています。一元化されたツールでは、通常、追加のインデックス作成ツールをセットアップする必要があります。