之前，我写了一篇文章《SVN为什么比Git更好》，主要是从非常朴实和现实的角度，从一个为全团队选型的角度，分析了为什么SVN比Git更好。但是公私分明，作为我个人来说，我想我还是更喜欢Git的。
全分布式设计
分布式计算，早就是这个时代的趋势和潮流了，为什么版本控制不应该分布式呢？分布式到底有何好处呢？很多书会写，每个拷贝，都是整个版本库的镜像，（这是优点么？），灾难恢复比较容易，（因为每个人镜像的人，都是整个全部版本库，多少个人克隆，就等同于多少分备份，那么当然灾难恢复容易，不过这跟我到底什么关系？那是运维的事情），去中心化，（那又怎么样？写代码难道还要民主不成？），这些分布式带来的好处，感觉都有点隔靴搔痒的感觉。
那么我个人真正从全分布式设计中，获得的好处是什么呢？我更喜欢创建版本库，并且保存所有的代码了。因为任何时候，使用Git工作，都是持有整个版本库，从0开始创建一个项目，也不例外，当你执行Git init的时候，就是真正有了一个版本库了，过程容易的程度，让人印象深刻。如果，使用SVN，则完全不会这么愉悦，因为是CS架构的，所有你总是要选择一个Server，就算全本地的场景，你也不得不安装一个SVN Server的一些软件，创建完了版本库，还要网络连接，还要checkout，即便所有的东西在本地，这个过程也并不迅速。而一旦版本库建立在了本地，日后想要迁移，恐怕也有得痛苦，因为SVN本身不提供这种迁移机制。Git的话则完全不同，一旦你需要传输某个项目到某个版本库，使用remote相关指令，轻松搞定。
Git的这种设计，会激发我将一切代码的目录，都变成版本库，反正又没什么成本，能保证代码不丢还能记录版本，何乐不为？
分布式设计的另一个妙处，就是全离线操作，无论是提交代码，创建分支，切换分支，分支合并，几乎一切的一切，都是本地操作。所以，只要一台电脑在手，在任何地方，任何环境，我都可以愉快地写代码，在过去的日子，我觉得这似乎并不是什么真实的需求，但是时代发展到了当今，我确实经常带着电脑到处跑，而且，更加习惯带着电脑出门了，在今时今日，这已经完全是一个频繁的需求了。
更强大的功能
以前，在SVN下面，很多东西都被限死了。虽然减少了错误的概率，但是毫无乐趣，毫无掌控力，用着很死板。使用了Git，就感觉到了很多强大的东西，这让我爱不释手。
其中一个能力是分支创建和切换的简便。以前SVN的分支创建，首先是一个服务器行为，你必须发指令给服务器，漫长的等待，其次，切换分支也是很痛苦的，需要从服务器下载差异，哪怕新创建的分支，执行switch也需要很久的等待。其次，SVN提供了merge tracking技术，如果一个分支经过多次merge操作，恐怕就并不会给出那么喜人的结果了，会变得非常不智能，甚至需要手动填写精确版本号，才可以正确地合并，所以我们常见的做法是，用完一个分支回归trunk后，就删除分支，下次重开，可是开分支真的很耗时，尤其版本库大的时候，所以，程序员经常偷懒，时常在trunk直接改bug，这其实是冒了风险的。
第二个是改变提交记录的能力。在SVN，任何东西都是一次提交，创建分支，提交，删除分支，提交，合并分支，提交，变更代码，提交，撤销变更，再提交。会产生很多很多的提交记录。为了不让自己的一次变更散落在太多commit里面（提交历史记录很不好看），我经常做法是降低提交频率，这更是冒着很大的风险的。使用了Git，就完全不一样了，我可以随意提交，甚至运行脚本自动提交，而当我真的想要归档的时候，可以使用交互式rebase，将之前的提交都合并成一个，可以挑选一些连续的提交，将他们按照功能划分后，合并成一个，这样就会产生非常清晰而且有意义的提交历史，并且不会导致代码丢失。好爽。
Git的rebase是我喜欢的另一个功能，因为commit本身已经不是顺序自然数了，所以，调整commit的顺序，人是无法感知的，只能靠时间戳分清先后，在这种情况下，调整了commit顺序如果能让提交历史更清晰的话，真的太棒了，rebase就是干这个的，我经常独立开发一个分支，脱离主干太久，这时候我只要rebase一下主干，下次我的代码回归主干的时候，看起来就像是自然而然append到主干最后的几个提交一样，完全是线性而且清晰的历史，再经过我精心合并后，就能产生很美的效果。
强大民主的社区