版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统，方便查看更改历史，备份以及恢复以前的版本，保证多人协作不出问题。

1，原始的版本控制

• 版本控制工具的黑暗时代：
  • 最原始的版本控制是纯手工的版本控制：修改文件，保存文件副本；
  • 保存副本命名随意，版本难辨新旧，不能辨别每一版的修改内容。

2，版本控制起源：diff & patch

• 在最初的版本控制软件出现之前，其实已经有了比较好用的源码比较与打补丁的工具：diff和patch。
• linus torvalds（linux之父）也对这两个工具偏爱有加。
• 在1991-2002年之间，即使cvs出现之后，linus一直使用diff和patch管理着linux的代码。
• diff与patch是用于源码版本控制中的两个最基本的概念。
• cvs（concurrent versions system）：协作版本系统。

2.1，diff简介

• diff用来比较两个文件或者目录之间的差异。

2.2，patch简介

• patch是diff的反向操作
• 我们把上述差异结果保存到文件中，例如：diff.txt中，那么这个diff.txt就可以用来从left.c推算出right.c的内容，反之亦可。

通过diff.txt，把left.c变成right.c的内容：

$ patch left.c diff.txt

• 上面执行的命令的意思是，把diff.txt应用到left.c文件上，命令结束后left.c与right.c中的内容是一样的。

通过diff.txt，把right.c变成原来left.c的内容：

$ patch -r right.c diff.txt

• 上面执行的命令中多了一个-r，其代表的意思是把diff.txt采用反向的方式，应用到right.c上，命令结束后right.c与left.c中原来的内容是一样的。

3，rcs：最早期的本地版本控制工具

• rcs（revision control system）
• rcs作为非常古老的版本工具，远远在svn和已经退役的cvs之前，它的古老程度应该比web开发的asp前代的cgi还要更久远。
• 如果想对版本管理实现方式进行深入研究的话，研究rcs是一种最为简单的入手方式。
• rcs采用把diff的集合，采用rcs自己的格式保存到磁盘中（可以通过diff -n left.c right.c产生rcs格式的diff内容），能通过这些diff集合，重新回到文件修改的任何历史中的点。

4，cvs & svn：集中式版本控制工具

cvs简介

• cvs（concurrent versions system）诞生与1985年，有史以来第一个被大规模使用的版本控制工具。cvs的出现让工程师可以协同工作。

cvs存在的问题

• 不支持原子化提交，会导致客户端向服务器端提交了不完整的数据，还有网络传输效率低等。

svn诞生

• svn（subversion）目的是创建一个更好用的版本控制以取代cvs。优化了服务器上内容的存储，实现了原子提交等。

svn存在的问题

• 在局域网之外使用svn，单是查看日志、提交数据等操作的延迟，就足以让基于广域网协同工作的团队抓狂了。

集中式版本控制存在的问题

• 狭窄的提交通道提交排队，不能同时修改，提交缺乏质量控制。缺乏代码门禁，在本地代码提交到服务器之间缺少检查防护。一种解决方案：rietveld提供旁路检查
• 数据安全性差单点故障黑客攻击

5，git：linus的第二个伟大作品

5.1，git起源

• linux之父linus是坚定的cvs反对者，他也同样地反对svn。2002年linus顶着开源社区精英们的口诛笔伐，选择了一个商业版本控制系统bitkeeper作为linux内核的代码管理工具。和cvs/svn不同，bitkeeper是属于分布式版本控制系统。
• git诞生大事件2005年4月3日，开始开发git。2005年4月6日，项目发布。2005年4月7日，git就可以作为自身的版本控制工具了。2005年4月18日，发生第一个多分支合并。2005年4月29日，git的性能就已经达到了linus的预期。2005年6月16日，linux核心2.6.12发布，那时git已经在维护linux核心的源代码。

5.2，集中式 vs 分布式

集中式 vs 分布式（1）：记录差异还是记录快照

• git和其他版本控制系统（包括subversion和近似工具）的主要差别在于git对待数据的方法。
• 概念上来区分，其它大部分系统以文件变更列表的方式存储信息。
• 这类系统（cvs、subversion、perforce、bazaar等等）将保存的信息看作是一组基本文件和每个文件随时间逐步积累的差异。
• git不按照以上方式对待或保存数据。反之，git更像是把数据看作是对小型文件系统的一组快照。
• 每次提交更新，或在git中保存项目状态时，它主要对当时的全部文件制作一个快照并保存这个快照的索引。
• 为了高效，如果文件没有修改，git不再重新存储该文件，而是只保留一个链接指向之前存储的文件。git对待数据更像是一个快照流。

集中式 vs 分布式（2）：脆弱的中央库 vs 强壮的分布库

• 脆弱的中央库备份的重要性集中式cvs存在单点故障，备份极其重要。服务器压力基本上所有的操作需要与服务器交互，操作受限于带宽，不能移动办公。安全性集中式cvs假定服务器是安全的。假定成立吗？存在单点故障，黑客攻击等。不适合开源项目强调集中管理，适合人数不多的项目。
• 强壮的分布库全是服务器数据最安全；无带宽和性能瓶颈。提交为本地操作快；全离线操作；编码不会被冲突打断；能够移动办公。数据的完整性git数据、提交全部使用sha1哈希，以保证完整性，甚至提交可以使用pgp签名。工作模型适合分布式开发，强调个体。git容灾示例kernel.org 2011 attack(2011.8-2011.11)宇宙射线反转磁盘一个比特的数据修复

5.3，选择合适的版本控制工具

• svn不适合的领域跨地域的协同开发对代码的高质量追求和代码门禁
• git不适合的领域不适合word等二进制文档的版本控制，因为：git无锁定/解锁模式，故不能排他式修改。整体的读授权，不能将读授权精细到目录级别，解决方案：版本库按照目录拆分。

6，结语：git是什么

• git是一个版本控制工具，而且是一个开源的分布式版本控制工具。
• 按照linus本人的描述，git的很多命令设计是来源于bitkeeper，但是git有更多属性：极快的速度简单的设计对非线性开发模式的强力支持（允许成千上万并行开发的分支）完全分布式有能力高效管理类似linux内核一样的超大规模项目（速度和数据量）

7，小结

• 版本控制工具的发展历史经过：原始人工维护状态，本地rcs，集中式如cvs、svn和分布式如git。
• 版本控制工具提供了协作开发的能力，借助它们我们可以回到任何时间的代码状态。
• 集中式版本控制工具，几乎所有的动作都需要服务器参与，并且数据安全性与服务器关系很大。
• git是分布式版本控制工具，除了与服务器之间进行按需同步之外，所有的提交操作都不需要服务器。