版本控制系统（Version Control System）是一种记录文件修订记录、帮助开发者追踪、维护源码、配置文件以及二进制文件等改动，并且提供控制这些改动控制权的程序。这里主要介绍一下版本管理的概念及 Git 的安装。

版本控制

在最简单的情况下，软件设计师可以自己保留一个程序的许多不同版本，并且为它们做适当的编号。这种简单的方法已被用在很多大型的软件项目中。该方法虽然可行，但不够有效率。除了必须同时维护很多几乎一样的源码备分外；而且极度依赖软件设计师的自我修养与开发纪律，但这却常是导致错误发生的原因。

有时候，一个程序同时存有两个以上的版本也有其必要性，例如：在一个为了部署的版本中程序错误已经被修正、但没有加入新功能；在另一个开发版本则有新的功能正在开发、也有新的错误待解决，这使得同时间需要不同的版本并修改。

此外，为了找出只存在于某一特定版本中（为了修正了某些问题、或新加功能所导致）的程序错误、或找出程序错误出现的版本，软件除错者也必须借由比对不同版本的代码以找出问题的位置。

版本管理涉及团队协作，产品质量，和产品上线。使用版本控制工具可使我们自由的做的以下几点：

• 回退到任意版本
• 查看历史版本
• 对比两个版本差异

时至今日，版本控制系统大致经历了四个阶段，先来看从网上找到的一张版本管理时代变迁图 :

本地版本控制系统

最简单的版本控制是手动版本控制，就是保留软件不同版本的数份备份，并且适当编号。许多大型开发案都是使用这种简单技巧。虽然这种方法能用，但是很没效率。一是因为保存的数份备份几乎完全一样，也因为这种方法要高度依靠开发者的自我纪律，而常导致错误。因此，有人开发出了将部分或全部版本控制工作自动化的版本控制系统。

本地版本控制系统 (LVCS)

本地版本控制系统中最流行的一种叫做 RCS（Reversion Control System），RCS 利用本地版本数据库保存补丁集（补丁是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各个版本的文件内容。 它可以迅速找出需求的版本和维持工作目录结构。其缺点是不支持协同开发，这也让开发者不将其选做通用的版本控制工具来使用的原因。

集中式版本管理系统 (CVCS)

集中式版本管理系统，诸如 CVS、Subversion 以及 Perforce 等，利用中央服务器来管理文件版本，但每一次操作都需要网络请求，且具有致命的单点故障。中央服务器故障可导致无法协同工作或数据丢失。

分布式版本管理系统 (DVCS)

分布式版本管理系统，例如 Git、Mercurial、Bazaar 以及 Darcs 等，每一份本地仓库都是一个完整的代码仓库镜像，即使一份仓库丢失或者损坏也可以从其他的仓库中获取此项目的完整历史记录。

版本控制中的一些术语

基线（Baseline） 基线是软件文档或源码（或其它产出物）的一个稳定版本，它是进一步开发的基础。

文件库（Repository） 存储文件的新版本还有历史数据的地方，通常是在服务器上。有时候也叫 Depot（像是在SVK、AccuRev还有Perforce中）

工作版本（Working copy） 从文件库中取出一个本地端（客户端）的复制，针对一个特定的时间或是版本。所有在文件库中的文件更动，都是从一个工作版本中修改而来的，这也是这名称的由来。观念上，这是一个沙盒。

提交（Commit） 将本地端的修改送回档案库。（由版本控制软件处理“跟上次更动相比，哪个文件又被更动”的事）

变更（Change） 对一份文件作的特定更动。

变更记录（Change List） 对一份文件作更动历史。

取出（Check-Out） 从文件库取出文件到本地端（客户端）。

更新（Update） 将文件库的修改送到本地端（与提交相反）

合并（Merge / Integration） 合并各个改变。

版次（Revision） 一个 revision 或 version 指的是一系列版本变迁的其中之一。

冲突（Conflict） 当两方更动同一份文件会发生冲突。

Git 介绍

Git 是一个免费开源的分布式版本控制系统，它也一个基于内容寻址的存储系统。Git 的第一个版本是 Linux 之父 Linus Torvalds 设计和实现的（据说只用了一个周末）。2005 年，开发 BitKeeper 的公司和 Linux 内核开源社区解除了合作关系，Linus 决定自己开发一个版本管理系统，这就是 Git。

Git 基于 DAG 结构 (Directed Acyclic Graph)，运行起来速度相当快而且对非线性开发模式的强力支持（允许成千上万个并行开发的分支）。Git 是一个完全分布式的版本管理系统，几乎所有操作都是本地执行的，有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）。在 Git 发布后，世界上几乎所有的大型的开源项目全部从 Subversion 迁移到了 Git 上。

文件的三种状态和 Git 的四个工作区域

Git 管理下你的文件有三种状态：已提交（committed）、已修改（modified）和已暂存（staged）。已提交表示数据已经安全的保存在本地数据库中。 已修改表示修改了文件，但还没保存到数据库中。 已暂存表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。由此引入 Git 项目的三个工作区域的概念。第一个是你的工作区(Workspace)，它持有实际文件，是你可以直接看到和编辑的；第二个是暂存区（Index）,它像个缓存区域，临时保存你的改动；最后是版本库(Repository)，分为本地仓库和远程仓库。另外还有一个特殊区域 stash，用来保存当前工作区和暂存区的状态。不同的区域中可以存在文件的独立版本。

文件生命周期

工作区下的每一个文件只有两种状态：已跟踪(Tracked)和未跟踪(Untracked)。已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后，它们的状态可能处于未修改(Unmodified)，已修改(Modified)或已放入暂存区(Staged)。工作目录中除已跟踪文件以外的所有其它文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有放入暂存区。编辑过某些文件之后，由于自上次提交后你对它们做了修改，Git 将它们标记为已修改文件。 我们逐步将这些修改过的文件放入暂存区，然后提交所有暂存了的修改，如此反复。所以使用 Git 时文件的生命周期如下：

在Git中，用HEAD表示当前版本,指向你最近一次提交后的结果。，上一个版本就是HEAD^，上上一个版本就是HEAD^^，往上100个版写成HEAD~100。 Git支持多种协议，包括https，但通过ssh支持的原生git协议速度最快。

基本的 Git 工作流程

1. 在工作目录中修改文件。

2. 暂存文件，将文件的快照放入暂存区域(git add)。

3. 提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录(git commit)。

Git 安装

Windows 下安装 msysGit

Mac OS X 下使用 brew install git 下载更新既可。

Linux Ubuntu 下可使用 apt-get install git 既可。

CentOS/RHEL 下使用 yum install git 安装。