2015第28周六SVN和Git

svn作为一个优秀源码版本的管理工具，可以适合绝大多数项目。但是因为它的采用中心化管理，不可避免的存在本地代码的备份和版本管理问题。也就是说对于尚未或暂无法提交到Subversion服务器的本地代码来说，存在着被误删除和版本更新无法回退两大情形。

git作为一个分布式版本管理工具，可以很好的解决这个问题。因为它的大多数操作是在本地进行的。这里要说的是git是如何做到既可以管理好本地代码又可以与已有的SVN中心库进行同步的。支持去中心化，是Git与生俱来的特性，它在本地保留了从中心服务器clone出来的源码库的全部信息，这样，你在本地修改完代码后便可以直接提交到本地 的代码版本库中。本地代码的备份和版本管理的问题就这样被Git轻而一举的就解决了。而本地源码库与SVN中心源码库的同步操作则是由Git提供的 git-svn工具来完成的。

但Git无法完全取代SVN，很多非纯技术开发公司更倾向于svn：
1.服务器公司统一控制管理
2.安全机制, 不会每个人都拷贝一份, 可以对组员限制, 也可以分配不同组
3.团队合作开发起来传递的数据量不会过大, git因为都是镜像, 如果有个美工传个500mb的psd, 不相关的人员也要去下载, 很浪费流量和更新时间
4.subversion感觉搭建非常简单支持https, 可以外部网络访问, 可以让员工在家办公, 也不用担心传递数据的流量(好邪恶)
5.每个人的电脑大小不一定能装下特别大的项目, 对于svn来讲, 公司配备一个足够大的服务器硬盘就好了, 而且哪个项目完成, 直接删掉本地目录就好, 完全没有保留的必要
6.网游公司, 广告公司这些需要大量媒体设计混合到程序的项目中, 很需要svn这样的服务器.
7.svn相对于git分支确实弱爆了, 但是并不能通过鄙视svn就能把所有人的习惯改过来.

git在这方面来讲更倾向于开源和纯代码开发。

两者设计上的几点不同：
1. svn基于revision,也就是delta，git基于状态，每个commit保存了完整的工作区目录；
2. svn在单分支上是一条revision的时间线，git则是由commits组成的DAG；
3. branch的设计，svn是revision-on-write, git是在DAG上加一个引用。也就是svn的分支从创建时刻起到合并之日前就是一条独立的时间线。而git的分支则是在分分合合的时间线上打的一个个引用;
4. 基于前几点，git得以轻松设计成分布式VCS:远程的服务器的上的内容仅仅是另一个分支而已；

git优势：
1. 分布式 去中心化使得更大的团队的维护变得容易。代码管理不再是分支和commit流程的管理，而是git网络拓扑的管理。谁负责向最终仓库merge，谁再外围负责接受其他用户的pull request。而不管你是否处在管理的核心，你都有权检出和修改整个项目的代码；
2. 分支合并的方便和速度提升。基于revision的版本控制有一个弱点，就是在和合并时要将直至公共祖先前的所有revisions用复杂的算法重演才能完成合并的过程。而基于状态的git在合并时，只需要在公共祖先，两个分支的最新commit间发起一个3-way merge就可以了。因此git的合并速度出奇的快。也因为如此分支创建无以伦比的简单；
3. 微commit和微branch。git可以任意的commit和branch使得VCS对代码的控制可以达到非常细的粒度。每一个小的修改都可以立即commit，每一个小功能/fix都可以branch。这使得测试一个小修改该和drop一个小功能都非常的容易。甚至你可以随便将另外一个分支的某个commit直接打过来用在当前分支上(cherry-pick)。使得用户面临频繁的需求变动也可以轻松的管理代码。

git缺点：
1.目录级别的访问控制，让有的成员只能访问某一目录(通常是模块)；
2.直观的版本号；
3.部分检出一个目录，通常是一个模块/分支；

最后附上 TortoiseSVN对比doc、excel文件比较工具设置方法：