1 起步
1.1 关于版本控制
-
什么是版本控制？
**版本控制（Version Control）**是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。
当我们谈论版本控制时，可以把它想象成一个"时间机器"，它可以帮助我们跟踪文件的变化，就像是在时间线上移动一样。让我通过一个通俗易懂的例子来解释：
生活中的例子：小明的故事本
想象一下，小明正在写一本自己的故事，他每天都在添加新的内容。但是，他发现管理这本书的不同版本变得有点混乱，有时候他会不小心删除了一些好的段落，或者不记得之前写了什么。
这时，小明决定使用一个"时间机器"来帮助他管理他的故事本。他找来一本笔记本，开始在每个重要的时间点写下他的故事内容，同时标记日期和时间。每当他做了一些重要的更改，他都会创建一个新的页面，而不是直接在原有的内容上修改。这样，他就可以随时翻阅笔记本，看到他故事的不同版本，也可以方便地找回之前写过的段落。
当小明发现他之前写的某一段更好时，他只需要翻回去，把它复制到当前的版本中。如果他犯了错误，不小心删除了内容，他也可以从之前的版本中找回来。最重要的是，他可以清楚地看到每个版本的变化，以及谁在什么时间做出了修改。
在这个例子中，小明使用笔记本就像是使用了一个简单的版本控制系统。而在实际的计算机工程中，我们使用专门的版本控制工具，例如Git，来管理代码和文件的变化。这些工具让开发团队能够更好地协同工作，跟踪变化，回退到之前的版本，并避免混乱和冲突。
-
版本控制系统的发展
**版本控制系统（Version Control System，VCS）**经历了不同阶段的发展，从最初的本地版本控制到分布式版本控制，为软件开发和文档管理提供了更高效、更强大的工具。以下是版本控制系统发展的三个主要阶段：
- 本地版本控制： 在早期，人们使用简单的本地版本控制方法，如复制文件来创建备份，或者使用一些工具来记录文件修改的时间和内容。然而，这些方法在多人协作时面临问题，无法有效地分享和同步文件。
（图片源于参考第一篇）
- 集中化版本控制系统（Centralized Version Control System，CVCS）： 为了解决多人协作的问题，出现了集中化版本控制系统，如CVS和Subversion（SVN）。在这种模型中，有一个中央服务器存储所有文件版本，团队成员通过连接到服务器来协同工作。然而，仍然有单点故障和依赖中央服务器的问题。
（图片源于参考第一篇）
3. **分布式版本控制系统（Distributed Version Control System，DVCS）：** 分布式版本控制系统引入了一种更加灵活和鲁棒的方法，最著名的是Git和Mercurial。每个用户都有一个完整的存储库副本，这意味着即使中央服务器崩溃，每个用户仍然有完整的历史记录和文件。团队成员可以在各自的本地存储库上工作，然后通过合并来共享和整合更改。这种分散的方法更适合大型项目和分布式团队。
（图片源于参考第一篇）
1.2 Git简史
同生活中的许多伟大事物一样，Git 诞生于一个极富纷争大举创新的年代。
Linux 内核开源项目有着为数众多的参与者。 绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。 到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。
到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。 这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds）基于使用 BitKeeper 时的经验教训，开发出自己的版本系统。 他们对新的系统制订了若干目标：
- 速度
- 简单的设计
- 对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
- 完全分布式
- 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）
自诞生于 2005 年以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。 它的速度飞快，极其适合管理大项目，有着令人难以置信的非线性分支管理系统（参见 Git 分支）。
1.3 Git基础
在学习Git的操作之前，我们先学系一下Git的思想和基本的工作原理。
1.3.1 直接记录快照，而非差异比较
与其它版本控制系统不同的是，Git使用快照来进行版本控制，它关心的是文件整体是否发生变化。其它版本控制系统更多的是关心文件内容是否发生改变。
（图片源于参考第一篇）
如上图所示，这类版本控制系统以一组基本文件和每个文件随时间逐步积累的差异组成。
（图片源于参考第一篇）
> Git 不按照以上方式对待或保存数据。 反之，Git 更像是把数据看作是对小型文件系统的一组快照。
1.3.2近乎所有操作都是本地执行
在 Git 中的绝大多数操作都只需要访问本地文件和资源，一般不需要来自网络上其它计算机的信息。
1.3.3 Git 保证完整性
Git 中所有数据在存储前都计算校验和，然后以校验和来引用。
1.3.4 Git 一般只添加数据
你执行的 Git 操作，几乎只往 Git 数据库中增加数据。
1.3.5 Git三个分区
工作目录、暂存区域、本地Git仓库
Git 仓库目录是 Git 用来保存项目的元数据和对象数据库的地方。 这是 Git 中最重要的部分，从其它计算机克隆仓库时，拷贝的就是这里的数据。
工作目录是对项目的某个版本独立提取出来的内容。 这些从 Git 仓库的压缩数据库中提取出来的文件，放在磁盘上供你使用或修改。
暂存区域是一个文件，保存了下次将提交的文件列表信息，一般在 Git 仓库目录中。 有时候也被称作``索引''，不过一般说法还是叫暂存区域。
1.4 Git安装
网上有许多教程···
1.5 初次运行Git前的配置
Git有三个配置信息的文件：
/etc/gitconfig文件：包含系统上每一个用户及他们仓库的通用配置。 如果使用带有--system选项的git config时，它会从此文件读写配置变量。~/.gitconfig或~/.config/git/config文件：只针对当前用户。 可以传递--global选项让 Git 读写此文件。.git/config文件：当前使用仓库的 Git 目录中的config文件：针对该仓库。
-
它们的关系类似于局部变量与全局变量的关系，作用的范围不同。
-
优先级为：
/etc/gitconfig文件 <~/.gitconfig或~/.config/git/config文件 <.git/config文件 -
通过上面三个文件，我们可以灵活配置git仓库信息
用户信息配置
bash
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com我们可以使用上面命名将知己的用户名称与邮件地址配置到全局变量中。这样做很重要，因为每一个 Git 的提交都会使用这些信息，并且它会写入到你的每一次提交中，不可更改。
如果你想针对不同的仓库使用不同的用户名与邮件地址的话，你可以在项目的根目录下运行没有--global选型的命令来配置。
配置代理
当我们从github克隆仓库的时候可能会很慢，这时你就可能需要配置代理了。
-
针对所有域名的仓库
bashgit config --global http.proxy <protocol>://<host>:<port>- --global选项:配置全局代理，去掉配置单个仓库代理
- 指的是代理协议，如 http，https，socks5 等。
<host>为代理主机<port>则为代理端口号- 常见误用 ：
git config --globalhttps.proxy <protocol>://<host>:<port>，这一写法完全是错误的 。请记住: Git 代理配置项正确写法 为http.proxy，并不支持https.proxy这一错误写法。
-
**针对特定域名的仓库
bashgit config --global http.<url>.proxy <protocol>://<host>:<port>- 多了个
<url>可以指定域名
- 多了个
详细信息可以参考： 一文让你了解如何为 Git 设置代理 - Eric (ericclose.github.io)
检查配置信息
我们可以使用git config --list来查看我们上面配置的信息是否正确。
删除配置
bash
git config [--global] --unset <配置名>1.6 帮助
当我们学习Git的时候，帮助是必不可少的，我们不可能一直清晰的记住所有命令，而且它还会向前发展，命令会发生改变。
git help:获取命令简要信息git help <verb>或git <verb> --help:获取具体用法- 为（1）查出的命令
幸运的是这些文档不用联网，但是需要一点点英语基础。
总结
经过上面的了解，相信你已经对Git这个工具有了一点了解，想要迫不及待的学习它的操作了。那么一起期待作者的下一篇关于git的文章吧。
参考
关于版本控制 · Pro Git 第二版 简体中文 (gitbooks.io)