公司使用的版本控制工具是SVN，自己的资料版本控制则是使用的git，并且托管与github上。最近再次折腾了git，对其有了些深入的了解。下面记录自己的一些理解和思考。主要有是git的两个亮点特征，分布式版本控制和强大的分支管理功能。
分布式的git
git是一个分布式的版本控制工具，版本控制信息（就是版本仓库repo，.git目录）可以保存在本地，并不依赖网络和中心服务器。当然，如果是团队协同开发，那么总需要一个地方来保存和合并最终的代码，那时候就需要网络和中心服务器。
SVN是一个集中式的版本控制工具。集中式的SVN，版本的控制文件等都集中放置在中心服务器上，本地只是一个拷贝，一个工作的过程就是update->modify->commit。update指将本地的拷贝更新到服务器上的版本，commit指将本地的修改上传到服务器上，产生一个新的版本。区别与git的commit操作，git的commit操作是将修改写入本地的版本仓库.git目录。
下面我们来看一个实际情况。你想将自己电脑上的某份代码做一个版本控制，如果这份代码就你一个人维护，无须上传到服务器，或者你压根儿就没有网络。还可以增加一些条件，例如你想将这份代码用U盘拷贝到其它电脑上工作。你总不至于为此在自己的电脑上安装一个SVN的服务端吧。基于上面的这些简单的日常个人应用，git就能够轻松帮你搞定：本地一个目录，就能够作一个版本，不需要服务器端，所有的版本信息都保存在本地的一个目录下。当然，如果你要多人协同开发，你也看可以为git架设中心服务器端。例如github就是这样一个服务器端。
分支管理的git
git的分支管理在本地建立分支，和SVN的分支不是同一个概念。
想想这样一个情况：你将本地的代码更新到了SVN服务器上的最新版本了。然后你你就在本地的代码中作修改，想解决其中的问题1。也许忙活了整个上午，突然发现，对问题1的修改的测试中，发现了问题2。那么，首先，你需要验证问题2是SVN版本上代码就有的问题呢，还是对问题1的修改带来的呢？这时候，你应该怎么作呢？将代码都回溯到SVN版本，那么对问题1的修改怎么办，这可是忙活了整个上午哦？将对问题1修改的文件拷贝出来，然后回溯到SVN上的版本。恩，先接收这个权宜之策吧。——修改的文件多时，你可就要抱怨的。如果验证发现，SVN上的版本就有问题2存在，而且，你发现，问题1和问题2的代码最好分别修改，以免互相影响，但是需要相互验证，测试。这个时候，你应该怎么办呢？
git则可以帮你轻松搞定这个问题。你在本地就可以建立多个分支，然后你在使用分支1解决问题1，分支2解决问题2。你可以轻松在分支之间切换，而且你还可以保持从服务器上pull下来的那个master分支的干净（也就是不做任何修改）。
举另外一个实际的例子，以前我所在的小组使用SVN作为版本控制工具，当我正在试图增强一个模块，工作做到一半，由于会改变原模块的行为导致代码服务器上许多测试的失败，所以并没有提交代码。这时候上级对我说，现在有一个很紧急的Bug需要处理， 必须在两个小时内完成。我只好将本地的所有修改diff，并输出成为一个patch文件，然后回滚有关当前任务的所有代码，再开始修改Bug的任务，等到修改好后，在将patch应用回来。前前后后要完成多个繁琐的步骤，这还不计中间代码发生冲突所要进行的工作量。可是如果使用Git， 我们只需要开一个分支或者转回到主分支上，就可以随时开始Bug修改的任务，完成之后，只要切换到原来的分支就可以优雅的继续以前的任务。只要你愿意，每一个新的任务都可以开一个分支，完成后，再将它合并到主分支上，轻松而优雅。（摘自活灵活现用Git-基础篇）
注：在上面的实例中，使用SVN，另外checkout一个copy就可以解决你老板给的紧急任务的切换问题。
网络资料
git的的特点介绍，分布式版本控制，方便的本地分支管理
个性化定制你的Git，更酷更巧妙的使用Git，以及如何在Git Hub上开启你自己的开源项目
介绍如何使用git的分支来建设团队软件开发流程，对于团队软件开发流程建设有参考价值。
来自书籍《Pro Git》，关于git分支的原理，深入了解git是如何实现本地分支管理，有利于阅读git源代码。
最近出版的一本关于git的书，由中国人自己写的。可惜我还没有看过，无法评价。下面给出本书介绍的链接。