代码版本控制用SVN还是Git好

SVN属于被淘汰的上一代版本管理工具。用SVN，你就属于被淘汰的一类。

GIT牛掰不仅仅是牛掰在离线提交这个方面。事实上本座的团队使用GIT根本没有考虑是否能离线提交，每个开发人员基本上走到哪里都可以有网，离不离线不是关键问题。

GIT牛掰的地方在于对分支管理，子项目依赖，代码冲突管理上比SVN高出不止一个数量级。

举个例子：用一个开源的库，我们需要对开源的库某些部分进行修改，但是又想保证该库紧跟官方发布不过时。用SVN的话，要不一切手动，要不你就把你的修改提交到官方源去（基本上是不可能的）。用GIT，我可以克隆一个repository，新建一条branch保持私有修改，官方库有更新随时pull --rebase。

GIT的commit还可以乱序修改。比如说队里的熊孩子搞砸了，一连几个commit都不能编译。太简单了：用git rebase -i可以把一条branch上的坏commit一个一个剔掉。换了SVN，提交了坏代码的话，天皇老子都没法改。

GIT的高级玩法多了去了。学习曲线比SVN要陡，但是培训下团队完全是值得的。现在业界主流都用GIT，数不清的各种工具和云服务都基于GIT。上Github下个代码，人家很潇洒地一站式git clone，你下个zip再解包不寒碜？

就算你是单干，GIT也比SVN好用的多。用SVN如果不用云服务的话你还得自己架一个SVN服务器，GIT的话直接本地repository。

能想出很多git优于subversion的地方，大部分是体现在分布式优于集中式的特征上，但如果你让我说出任何SVN分过来胜过git的地方，我竟一时想不出来一个。但这就能说明git完胜SVN吗？

事实当然不是这样，就像是Windows和Linux，你不能说这个一定就比那个好。最近在stackexchange的讨论让我学习了不少。先举个简单的例子证明有些地方你只能用SVN而不能用git。谷歌的搜索排名算法，就不能放到分布式开放的代码库了。

这种情况下SVN的集中式管理就是不二选择。下面就来条理的看看Subversion在哪些环境下比git更适用。

Subversion是集中式管理的数据仓库 虽然速度快和多副本等git分布式数据仓库显而易见的好处吸引了很多人的喜爱，但在很多情况下，一个集中式的数据仓库却是更合适的。例如，

如果你有一些核心代码想只允许部分人能访问，把它放到git里必然是你不希望的。很多的企业都是将它们的代码集中管理的，我猜，所有(重要)政府项目估计都使用的是集中式数据仓库的版本控制系统。

Subversion的理念符合常规思维 这是说，很多人(特别是管理者或老板)对版本号有一种习惯的认识，把开发视作一种按时间的线性发展轨迹，这在他们脑子里根深蒂固。并不是找借口，Git的随意性并不是很容易去理解，你也许注意到了，任何一本关于Git的书都会在第一章第一节告诉你要抛弃脑子里所有的传统观念，重新认识。

Subversion只提供一种途径，没有第二选择 SVN是一个版本控制系统，它只提供一种方式做这些，每个人都使用相同的方法。就是这样。这使得你将代码从SVN迁移到其它集中式管理的VCS或从其它集中式管理的VCS迁进来变得很容易。Git并不仅仅是一个版本控制系统——它实际上是一个文件系统，它里面有很多的拓扑学知识来支持你如何在不同的环境中架设代码仓库——并且没有一个统一的标准。选择一个合适...

鹏仔微信 15129739599 鹏仔QQ344225443 鹏仔前端 pjxi.com 共享博客 sharedbk.com