目录
关于版本控制
1. 定义
版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。可以对任何类型的文件进行版本控制，而不仅局限于软件源代码的文件。版本控制系统（VCS）。
2. 三种版本控制系统
（1） 本地版本控制系统
采用某种简单的数据库（database）来记录文件的历史更新差异。其中最流行的一种叫做RCS， 它的工作原理是在硬盘上保存补丁集；通过应用所有的补丁，可以重新计算出各个版本的文件内容。
缺点： 无法实现不同系统上的开发者协同工作。整个项目的历史记录被保存在单一位置，存在丢失所有历史更新的风险。
（2） 集中化的版本控制系统
Centralized Version Control Systems， 简称CVCS。诸如CVS、Subversion、Perforce等，都是一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连接到这台服务器，取出最新的文件或者提交更新。
优点： a. 协同开发的每个人都可以在一定程度上看到项目中的其他人正在做什么。
b. 管理员也可以轻松控制每个开发者的权限，且管理一个CVCS要远比在各个客户端上维护本地数据库更容易。
缺点： 中央服务器的单点故障。宕机， 无法协同工作； 中心数据库所在的磁盘发生损坏且没有做恰当备份，将丢失所有数据——包括项目的整个变更历史。
（3） 分布式版本控制系统
Distributed Version Control System，简称DVCS。例如Git、Mercurial、Bazaar 以及 Darcs等，客户端并不只是提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这样，任何一处协同工作用的服务器发生故障，都可以用任何一个镜像出来的本地仓库恢复。每一次克隆操作，实际上就是对代码仓库的完整备份的过程。
Git 简史
- 1991 ~ 2002年间 ， 绝大多数的Linux内核维护工作都花费在了提交补丁和保存归档的繁琐事务上；
- 2002年， 整个项目组开始启用一个专有的分布式版本控制系统BitKeeper来管理和维护代码；
- 2005年，开发 BitKeeper 的商业公司收回Linux内核社区免费使用BitKeeper的权力；
Linux开源社区基于Bitkeeper的经验教训，开发自己的版本系统。对新的版本管理系统制定了若干目标：
- 速度
- 简单的设计
- 对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
- 完全分布式
- 有能力管理类似于Linux内核一样的超大规模项目（速度和数据量）
Git简介
1. 直接记录快照，而非差异比较
Git 和其它版本控制系统（SVN等）的主要差别在于Git对待数据的方法。概念上来讲，其它大部分版本控制系统以文件变更列表的方式存储信息。Git把数据看作是对小型文件系统的一组快照，每次提交更新或者保存项目状态时，主要对当时的全部文件制作一个快照并保存这个快照的索引。为保证高效性，如果文件没有被修改，Git不重新存储文件，而只保留一个链接指向之前存储的文件。
2. 近乎所有操作都是本地执行
不依赖于服务器（有网络延迟的开销），本地就能完成大部分的操作，例如查看项目的历史。
3. Git 保证完整性
Git中所有数据在存储前都计算校验和，然后以校验和来引用。这意味着不可能在Git不知情时更改任何文件内容或目录内容。Git用以计算校验和的机制叫做SHA-1散列（hash，哈希）。Git数据库中保存的信息都是以文件内容的哈希值来做为索引的，而不是文件名称。
4. Git 一般只添加数据
5. 三种状态
- 已提交(committed) , 表示数据已经安全的保存在本地数据库中；
- 已修改(modified)， 表示修改了文件，还没有保存到数据库中；
- 已暂存(staged)，表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中
6. 三个工作区域
- Git仓库， Git用来保存项目的元数据和对象数据的地方
- 工作目录， 对项目的某个版本独立提取出来的内容，从Git仓库的压缩数据库中提取出来的文件，放在磁盘上供使用和修改
- 暂存区域， 保存了下次将提交的文件列表信息，一般在Git仓库目录中。
基本的Git工作流程如下：
（1）在工作目录中修改文件
（2）暂存文件，将文件的快照放入暂存区域
（3）提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录