聊聊版本控制
Git是一款分布式版本控制系统，有别于CVS和SVN等集中式版本控制系统，Git可以让研发团队更加高效地协同工作，从而提高生产率。
有很长一段时间Linus只使用diff、patch和tar包来管理Linux的代码。
大家平时在安装软件包的时候会发现软件包的名字后面有-svn,-git等等字眼。。到底有什么区别呢？看下面～～～
- RCS(Revision Control System) 修订控制系统，特点:
- 简单
- 使用Lock机制防止多个开发人员对同一个文件同时进行修改.
- CVS(Cocurrent Version System)并发版本系统,建立在RCS基础上,最流行的开放源代码版本控制系统,特点:
- 使用单一的主代码树,而不像RCS那样依赖多个目录.
- 最大优点在于多名开发人员可以同时对一个文件进行修改.允许合并.这就“并发“开发.
- SVN(SubVersion)
- 目录的版本控制,CVS 只能对文件进行版本控制，不能对目录进行版本控制.CVS 只能注意到，一个文件在一个位置被删除了，而在一个新位置创建了另外一个文件。由于它不会连接两个操作，因此也很容易使文件历史轨迹丢失,SVN可以
- 原子性提交,CVS 采用线性、串行的批量提交，即依次地，一个接一个地执行提交，每成功提交一个文件，该文件的一个新的版本即被记录到版本库中，提交时用户提供的日志信息被重复地存储到每一个被修改的文件的版本历史中。CVS 串行批量提交模式的弊端在于 －当任何原因造成批量操作的中断时（典型原因包括：网络中断、客户端死机等），版本库往往处于一个不一致的状态：原本应该全部入库的文件只有一部分入库，很有可能版本库中的最新版本不能顺利编译，更为严重的是，随着其他的用户执行cvs update 操作，该不一致性将迅速在开发团队中扩散，从而严重影响团队的开发效率，并存在质量隐患。另外，假如该批量提交的中断没有被及时发现，开发团队往往要花更多的时间进行软件调试和排错。
- Git, Git 是用于 Linux 内核开发的版本控制工具。与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持，使源代码的发布和交流极其方便。 Git 的速度很快，这对于诸如 Linux kernel 这样的大项目来说自然很重要。 Git 最为出色的是它的合并跟踪（merge tracing）能力。git更加适合分布式开发项目。而svn（当然全称是subversion）则更适合于集中式大型开发项目。也有在git之上再使用一层svn的做法。
几个版本控制
- 本地版本控制：这个可能是大多数人使用的方式，不同的名字或者时间信息等，但很容易混淆文件
- 集中化版本控制：有个单一的集中管理的服务器，保持所有文件的修改版本，容易管理，但万一服务器宕机，风险就超级大了
- 分布式版本控制：多地克隆备份
总结
CVS,Git,Mercurial,Subversion比较
| 特征 | CVS | Git | Mercurial | Subversion |
|---|---|---|---|---|
| 是否原子提交 | 没有 | 是 | 是的 | 是 |
| 文件和目录是否可以移动或重命名 | CVS: 不是. 重命名不支持. 如果手动进行, 可能会损坏历史记录 | Git: 支持重命名, 这是很实用的目的. git甚至能检测到重命名之后文件的改变. 尽管如此, 基于特殊的存储结构, 重命名不会被显示的记录, git能够推导出来(在实际使用中很容易做到) | 是的, 重命名是支持的 | 是的. 支持重命名 |
| 在移动或重命名之后智能合并 | CVS: 不能. 重命名都不支持, 就不必说智能了 | Git: 不支持. | Mercurial: 是的. 重命名之后智能合并是支持的. | 不支持. |
| 文件和目录拷贝 | 不能 | 不能 | 支持拷贝 | 拷贝非常容易(O(1)). 包括产生分支 |
| 远程存储仓库的备份 | 间接的. | git的内部特征 | 是的 | 间接的. |
| 是否传递变更到父仓库 | CVS: 不会 | 是的 | 是的 | 是的, |
| 仓库权限 | CVS: 很有限. | Mercutial: 是的. | Subversion: 是的. | |
| 变更集 | CVS: 不是. 变更是基于文件的 | Git: 是的. 是支持的, 创建他们很容易 | Mercurial: 是的. 变更集是支持的 | Subversion: 部分支持. 对于一次提交会隐式创建一个变更集 |
| 跟踪线性的文件历史 | CVS: 是的. cvs annotate | Git: 是的.(git blame) | Mercurial: 是的(hg annotate) | Subversion: 是的(svn blame) |
| 能够只在仓库的单目录下作用 | CVS: 是的 | Git: 不是. 尽管如此, 提交多少能被限制 | Mercurial: 能够基于某树的某个子集进行提交. 也有局部检出的能力 | Subversion: 是的 |
| 跟踪未提交的变化 | CVS: 是的. 通过cvs diff | Git: 是的. | Mercurial: 是的. 使用hg diff | Subversion: 是的. 使用svn diff |
| 基于单个文件的提交信息 | CVS: 不是. 提交信息是基于单次变化的 | Git: 是的. 提交信息基于变更集 | Mercurial: 不是 | Subversion: 不是. 没有这个特征 |
| 文档 | CVS: 非常棒. 有很多在线的tutorials和资源, 在线的书籍. | Git: 良好. 短的帮助比较简洁难懂. | Mercurial: 很好. 有基于公司的书籍和wiki. 每个命令都集成了帮助 | Subversion: 很好. 有一些在线的书籍和一些在线的tutorials和资源. 并且书籍是以docbook/xml写的 |
| 配置是否轻松 | CVS: 好. 是个事实上的标准. 基于每个系统都有并且很容易配置 | Git: 好. 在现有平台上二进制可用. 需要C编译器和Perl. 在windows上需要cygwin. 并有一些Unix特征 | Mercurial: 非常好. 几乎所有平台都有二进制包. 从源码编译需要python2.3以上, 并且需要C编译器 | 有些复杂 |
| 命令集 | CVS: 包含了3个经常用到的命令的简单的命令集(cvs commit, cvs update和cvs checkout)和其它一些 | Git: 命令集很丰富, 并且和CVS不兼容 | Mercurial: 尝试模仿CVS交互方式, 但是偏离了基于不同的设计的意图 | Subversion: 类CVS的命令集, 能够很容易被CVS用户使用 |
| 网络支持 | CVS: 好. cvs在不同的场合使用不同的协议. 协议能够通过ssh链接的加密隧道进行 | Git: 非常棒. 能够使用本地的git协议, 但也能在rsync, ssh, HTTP和HTTPS上使用 | Mercurial: 非常棒. 使用HTTP或ssh. 远程访问会非常安全, 在只读网络里不需要上锁 | Subversion: 非常好. Subversion服务器支持WebDAV+DeltaV(基于HTTP或HTTPS)作为底层协议, 或者它自身的协议同样能在ssh链接通道里使用. |
| 可移植性 | 客户端能在UNIX, Windows和Mac OS上使用. | 客户端运行在大多数的UNIX系统上, | 运行在基于所有能运行python的平台 | 客户端和服务器端都能在UNIX, Windows和Mac OS X上运行 |
| web接口 | .CVSweb, ViewVC, Chora和wwCVS | Gitweb | Mercurial: 是的. Web接口是内置组件 | ViewVC, SVN::Web, WebSVN, ViewSVN, mod_svn_view, Chora, Trac,SVN::RaWeb::Light,SVN Browser, Insurrection和perl_svn. |
| 图形用户界面 | WinCVS, Cervisia, TortoiseCVS | Gitk,Qqit和Git-gui | Hgit,hgct | RapidSVN, TortoiseSVN, Jsvn(java), |
Git 是什么
Git与其他版本控制系统的区别，其他的一般基于差异delta-based版本控制，如下：
而git是基于快照流的，如下：
近乎所有的操作都是本地执行。
