为什么DVCS似乎都具有未落实变更的不合理恐惧症？

来自SVN背景，使用DVCS系统时要适应的最困难的事情之一就是，它们似乎都将任何未提交的更改视为滴答定时炸弹。

在Mercurial中，如果您尝试获取更改，并且您的工作副本中有任何未提交的更改，则必须跳过所有步骤以使其仅合并传入的更改。尝试切换分支吗？这将迫使您搁置所有内容，然后必须立即在另一端立即搁置所有内容。（SVN在这两种情况下都没有问题。）

Git大致相同。我正在与另一个项目的开发人员并肩工作，而我只是试图将他的提交之一挑进我的叉子中。它拒绝让我，因为我的工作副本中的更改尚未提交，与他提交中的更改完全不同的文件。 甚至没有合并选项。显然，我必须先隐藏我的更改！

如果一个人以这种极端的谨慎对待完全无害的东西，我会称其为“恐惧症”，这是一种非理性的恐惧，应视为精神障碍。但是Git和Mercurial是由两个不同的聪明，理性的开发人员团队设计的，所以我不得不怀疑他们是否知道我所不知道的东西。

是否有技术上的理由证明这种对待未承诺变更的态度是正确的？如果是这样，为什么问题仅在DVCS上存在？

1. 在DVCS世界中，提交是廉价的，历史是可变的。WIP可以根据需要设置为“脏”：而且我看不出有任何理由反对“将我的当前状态放入更改集中进行存储”
2. SVN历史是线性的，因此-您必须将草稿与新修订中的更改合并。DVCS（自然地）使用DAG，并且额外的头部（commit + pull + up）用于分散历史记录，比在运行中修改工作目录与获取外部更改合并更安全。
3. 当您在Subversion中切换（到某个节点）修改的WC时，您摆脱了一个潜在的附加合并（与“ commit to old”-“ switch”-“ merge 1 rev。range”相反）...并且我们知道：merges SVN中的工具并不是完美的工具，而DVCS则根本不是问题

恢复

这不是恐惧症，是（有时很苛刻）强制遵循“经常提交”的良好举止（SVN用户有时会害怕这种风格）

而且，最后hg qnew|qpop|qpush是为了整洁和秩序的小公道价格

当您合并或选择时git，您将立即创建一个提交。直到该提交完成并成为历史的一部分，该操作才完成。

现在，如果git允许您掩盖工作目录中未提交的更改会怎样？您将（或多或少）难以区分要为合并/樱桃选择而需要处理的更改/合并冲突，以及您自己介绍的更改。而且，您几乎不可能测试您实际提交的内容。

因此，在合并情况下强制使用干净的工作目录有助于使事情简单且易于管理。毕竟，您所需要做的就是在合并之前存储未提交的更改，然后在存储之后存储它们。注意，在工作流程中

git stash
git pull
git stash pop

您有两个（！）合并操作。一种将您的最后一次提交与传入的更改合并，另一种将您未提交的更改与结果合并提交合并。这样，您只需要将两件事合并为一，就可以避免由于试图在一次操作中将三件事合并为一而忽略这三件事而造成的混乱。该git stash/ git stash pop很容易和明确的，你是忽略你的合并提交的更改。