从心态上来说，有时能够创建一个软分支，执行软分支中的所有更改，测试软分支中更改的结果，然后当软分支“完成”时会有一个好处”，在本地将其与主分支重新集成，重新测试，然后传播。
在某些情况下，这比匆忙的头脑要好，因为您不会因为其他调试代码的存在而不断中断，从而弄乱您的代码以添加非错误来处理。
这也意味着您可以更频繁地提交，提供更全面的历史记录，因为提交不会立即出现在任何地方，从而产生问题。
此外，当协调软分支与共享主线时，您可以看到一个很好的完整变更集，向您显示所有集体变更以及它们的所有集体变更，这为良好的代码审查机会打开了大门。
此外，从测试的角度来看，如果您有更多的软分支，您可以在将软分支合并回主分支之前运行测试，并制定一个标准，根据该标准，分支不会合并回主分支分支直到有
- 自行通过测试
- 主分支更改已协调到软分支后通过测试
从而为您提供了代码质量的额外保证，因为您的主要协作分支非常干净，因为不允许出现失败的代码。
（这也限制了解决问题的领域，因为大部分情况下你只需要测试自己的更改，当你“完成”时，你才需要担心其他人做了什么，以及他们做了什么还应该通过测试，这意味着当某事does失败了，你只需要看看是什么you确实解决了问题）
但我会持续更新吗
中央仓库进入我的软分支？
这确实是我的本质
问题
分支系统的美妙之处在于，您可以根据需要将“其他人认为稳定的任何内容”拉入本地副本。
“持续更新”变得没有必要，因为你不会再出现同样的问题。
a b center
|
|
/ Key: / - | \ = Flow
/----<---| < > = Flow Directions
| /--<--/ * = Commit
* | | T = Test
| * | M = Merging with "Current" state of common branch
* | | C = Tests Complete and Current state is "sane"
| * |
T | |
| T |
| C |
| |/-<--/
* M |
| T |
* C |
| \--->-\
* /---<-/
T | |
C * |
|/-----<-/
M | |
T * |
| T |
* C |
| |/-<--/
* M |
T T |
C \-->--\
|/---<---/
M |
T |
C |
\---->---\
|
此外，由于系统的工作方式，稍后也可能会发生这种情况：
a b center
| | |
T | |
C * |
|/</ |
M | |
| * |
T |
C |
|/----<--/
M |
T |
C |
\-->-----\
|
在这种情况下，他们作为“头”的整个概念就消失了。如果有几十个头，你看到哪一个就容易透视。
我还可以补充一点，这些逻辑分支虽然在这里显示为单独的，但可以非常可行地表示单独的结帐位置，或者仅表示单个计算机上的不同软分支。 a 和 b 实际上可以是单个开发人员。
本质上，“从主分支持续更新我的软分支”在概念上是没有意义的。因为事实上，还会有一些变化尚未在主分支中体现出来，你什么时候才能知道它们是否已被推送？ SVN 给你一种“单一”代码状态的错误幻觉，而实际上，当用户在文本编辑器中打开文件的那一刻，他们实际上创建了一个生命周期非常短的软分支，这是一种正在发生的变化，没有人知道这一点，并且为了让这种幻觉以您认为的方式持续下去，实际上，用户必须在每个字符之后进行提交，这几乎不切实际。所以在现实中，人们习惯了不同地点彼此“不同步”的事实，并学习解决它的方法，这样它就不再是问题了。
另外，“用其他人的更改不断更新我的树”有一个核心问题，即你有太多的干扰，你不断受到其他人正在做的所有事情的轰炸，如果他们正在制作一系列 1 line 承诺测试他们无法在自己的机器上测试的东西，然后你就会因为不断变化的文件而陷入噩梦，而用户看到看似随机的变化却无法理解它们。
通过允许提交之间的运行时间更长，然后查看最终结果batches并且只看到最终结果您的同行的所有更改都会立即发生，您可以立即看到自您签出以来更改了哪些代码，以及它对您的代码意味着什么的连贯概述，因此您可以编写自己的代码并完成它。
如果您有任何疑问
从简单的事情开始，不要突然转变，DSCM 中的一些概念可能有点令人畏惧（我见过许多人未能理解垂直堆叠软分支的概念），移动一个小的非- Git/Mercurial 代码库的重要组成部分，并使用它一段时间，尝试其优点和功能。没有比亲自体验更好的证据了，我所有可爱的解释都不太可能传达你需要理解的内容，只能通过尝试和失败几次来学习（因为失败是学习的关键部分）
