我总结使用DVCS的场景主要包括
1、中央仓库可能在远程，比如一个项目是多国完成，团队分布在不同大洲，每次向中央仓库提交更新都需要等到漫长的连接过程，所以使用Git或者Mercurial提交到本地，待网络状态良好情况下集中提交更适合。
2、开发人员经常需要离线提交，比如经常需要在飞机上，旅店里提交代码。
3、项目对特征分支（Feature Branch）要求很高，需要频繁创建分支，即便频繁分支非常不推荐使用，但是在某些场景下还是必不可少。虽然CentralizedVersionControl工具（比如SVN）能够创建分支，但是这些分支对所有人都是可见的，并非安全的sandbox，DVCS对于VCS的最大改进就在于对分支提供更加丰富的支持。
（1）实验分支：如果项目在主线开发到一定程度时，需要增加一个新的功能，新的功能是探索性的有可能成功也可能失败，有可能破坏主线，那么这个功能应该在分支中完成，如果成功了则merge到主线，如果失败了就当做没有过直接discard掉。
（2）发布控制：分支还可以用于版本发布的控制，比如某公司在做一个产品，他们发布产品特性速度取决于其他公司同类产品的进度，比如此产品需要增加特性A和B，如果此时其他公司产品还没有实现A功能，则如果发布只增加A功能的产品既能保证最大程度保留实力，也能在竞争中处于优势。就可以把A分支合并到主线构建发布，而B分支用作保留实力。
这两点在传统的VCS中很难做的完美。
有很多人一直抱怨DVCS大力鼓励FeatureBranch，导致项目Branch横行，带来了很多Merge的麻烦。关于这一点，DVCS虽然能提供不少功能支持分支，但是也取代不了人工合并的烦恼。（DVCS可以支持Text合并，但是语义合并还需要结合代码具体含义来人工调整）
没有根本解决合并烦恼的办法，但是的确有两种方式可以减缓疼痛。
1、尽量不要长线分支：即便在成熟的团队，也不要长线分支，通过程序集成工具，尽可能多的频繁合并，保证将最后合并之痛分摊到每日合并之中。
2、写自测试代码：尽量保证代码是可测试的，再每次合并之后用自动化测试最快速找到合并导致的错误，加以解决。
