DVCSにコミットされていない変更の非合理的な恐怖症がすべてあるように見えるのはなぜですか？

SVNのバックグラウンドから来て、DVCSシステムでの作業に慣れるのが最も難しいのは、時限爆弾のように、コミットされていない変更をすべての人がどのように考えるかということです。

Mercurialでは、変更をフェッチしようとして、作業コピーにコミットされていない変更がある場合は、フープをジャンプして、入ってくる変更だけをマージする必要があります。ブランチを切り替えてみますか？それはあなたにすべてを棚上げすることを強いるでしょう、そしてあなたは反対側ですぐにそれをすべて棚から外さなければなりません。（SVNはこれらのシナリオのいずれでも問題ありません。）

Gitもほぼ同じです。私はプロジェクトで別の開発者と並んで作業しており、彼のコミットの1つを私のフォークにチェリーピックしようとしました。私の作業コピーのコミットされていない変更が、彼のコミットで変更されたファイルとは完全に異なるファイルにあるため、許可されませんでした。 マージオプションすらありません。どうやら最初に変更を隠しておく必要があります！

人がそのような極端な注意を払って完全に無害なものを扱うとしたら、私はそれを「恐怖症」と呼びます。それは精神障害と見なされるべき非合理的な恐怖です。しかし、GitとMercurialはインテリジェントで合理的な開発者の2つの異なるチームによって設計されたので、私が知らないことを彼らが知っているのかどうか疑問に思う必要があります。

コミットされていない変更に対するこの姿勢を正当化する技術的な理由はありますか？もしそうなら、なぜ問題の問題はDVCSにのみ存在するように見えるのですか？

1. DVCSの世界では、コミットは安く、歴史は変更可能です。WIPは、必要に応じて「ダーティ」にすることができます。また、「変更セットの現在の状態をド​​ロップして保存する」という理由はわかりません。
2. SVN履歴は線形であるため、ドラフトを新しいリビジョンの変更とマージする必要があります。DVCSは（自然に）DAGを使用し、分岐履歴の追加ヘッド（commit + pull + up）は、フェッチされた外部変更を使用して変更された作業ディレクトリをオンザフライでマージするよりも安全です。
3. Subversionで変更されたWCを（一部のノードに）切り替えると、1つの潜在的な追加のマージ（「commit to old」-「switch」-「merge 1 rev。range」とは対照的）がなくなります...そして、私たちは知っています：マージSVNはツールの完璧な側面ではありませんが、DVCSにはまったく問題ありません。

履歴書

それは恐怖症ではありません、「頻繁にコミットする」という良いマナーに従うことは（時には厳しい）強制です（SVNユーザーは時々このスタイルを恐れています）

そして、ついに、hg qnew|qpop|qpush清楚さと秩序のための小さな公正な価格です

でマージまたはチェリーピックするとgit、すぐにコミットが作成されます。そのコミットが完了して履歴の一部になるまで、操作は完了しません。

gitでは、作業ディレクトリでコミットされていない変更を確認できるとしたらどうなるでしょうか。マージ/チェリーピックで処理する必要のある変更/マージの競合と、自分で導入した変更を区別するのは（多かれ少なかれ）困難です。また、実際にコミットしていることをテストすることはほぼ不可能です。

したがって、マージ状況に対してクリーンな作業ディレクトリを強制することは、物事をシンプルで管理しやすい状態に保つのに役立ちます。結局のところ、コミットする前の変更をマージ前に隠しておき、後でそれらを元に戻すだけでよいのです。なお、ワークフローでは

git stash
git pull
git stash pop

2つの（！）マージ操作があります。最後のコミットを着信変更とマージするもの、およびコミットされていない変更を結果のマージコミットとマージするもの。このようにして、2つのものを1つにマージするだけでよく、3つのものを1つの操作で1つにマージしようとしても、これらの3つを無視しようとすることによる混乱を回避できます。git stash/ git stash popマージのためのあなたのコミットされていない変更を無視していること、それは簡単で、明示的になります。