1 版本控制

1.1 什么是版本控制系统？

版本控制系统(Version Control System，简称VCS)，是一种记录一个或若干文件内容变化，以便将来查询特定版本修订情况的系统。版本控制系统不仅可以应用于软件源代码的文本文件，而且可以对任何类型的文件进行版本控制。

有了版本控制系统，我们可以将选定的文件回溯到之前的状态，甚至将整个项目回退到过去某个时间点的状态，我们可以比较文件的的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能的缺陷等等。使用版本控制系统通常还意味着，就算我们乱来一气把整个项目中的文件改的改删的删，我们也照样可以轻松恢复到原先的样子。但额外增加的工作量却微乎其微。

1.2 本地版本控制系统

本地版本系统大多都是采用某种简单的数据库来记录文件的历次更新差异。

其中最流行的一种叫做RCS，现今许多计算机系统上都还看得到它的踪影。RCS的工作原理是在硬盘上保存补丁集（补丁集是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各个版本的文件内容。

1.3 集中式版本控制系统

集中式版本控制系统(Centralized Version Control Systems，简称CVCS)：集中式版本库集中存放于一个单一的中央服务器，保存所有文件的修订版本。人们需要先从中央服务器取得最新的版本，然后开始干活，干完活后，在把自己的活推送给中央服务器。因此，集中式版本控制器需要在联网的情况下才能开始工作。

==缺点：==中央服务器的单点故障。如果宕机一小时，那么在这一小时内，谁也无法提交更新，也就无法协同工作。如果中心数据库所在的磁盘发生损坏，又没有做恰当的备份，所有的数据就会丢失——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。

1.4 分布式版本控制系统

分布式版本控制系统(Distributed Version Control Systems，简称DVCS)：分布式版本控制系统中没有“中央服务器”，在这类系统中，像Git、Mercurial以及Darcs等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来，包括完整地历史记录。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，我们就可以在同一个项目中，分别和不同工作小组的人相互协作。 我们可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。

2 Git简史

Linux 内核开源项目有着为数众多的参与者。 绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。 到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。

到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。 这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds）基于使用 BitKeeper 时的经验教训，开发出自己的版本系统。 他们对新的系统制订了若干目标：

• 速度
• 简单地设计
• 对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
• 完全分布式
• 有能力高效管理类似Linux内核一样的超大规模项目（速度和数据量）

自诞生于 2005 年以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。 它的速度飞快，极其适合管理大项目，有着令人难以置信的非线性分支管理系统（参见 Git 分支）。

3 Git的安装

3.1 在Linux上安装

这里我主要是在VMware虚拟机中的CentOS7上操作的，在terminal中输入命令：

$ sudo dnf install git-all

更详细的安装方式参考链接：安装Git

3.2 初次运行Git前的配置

当我们安装好Git后，还需要再terminal进行一些相关设置。

git config --global user.name "Your Name"
git config --global user.email "email@example.com"

除此之外，Git还有许多设置，包括常用编辑器等，可以键入如下命令查看设置并修改：

git config --list