git版本控制
复制完介绍部分后，突然发现此书有中文翻译版，故不续更了。附pdf链接：
https://github.com/progit/progit2-zh/releases/download/2.1.62/progit.pdf
1 介绍
1.1关于版本控制
1.1.1 本地版本控制
最流行的VCS（版本控制系统）工具之一是称为RCS的系统，该系统至今仍与许多计算机一起分发。RCS 的工作原理是将补丁集（即文件之间的差异）以特殊格式保存在磁盘上;然后，它可以通过添加所有补丁来重新创建任何文件在任何时间点的外观。
1.1.2 集中式版本控制系统
人们遇到的下一个主要问题是他们需要与其他系统上的开发人员协作。为了解决这个问题，开发了集中式版本控制系统（CVCS）。这些系统（如 CVS、Subversion 和 Perforce）具有一个包含所有版本控制文件的服务器，以及许多从该中心位置签出文件的客户端。多年来，这一直是版本控制的标准。
此设置具有许多优势，尤其是与本地 VCS 相比。例如，每个人都在一定程度上知道项目中的其他人在做什么。管理员可以精细控制谁可以做什么，并且管理 CVCS 比处理每个客户端上的本地数据库要容易得多。
但是，此设置也有一些严重的缺点。最明显的是集中式服务器所代表的单点故障。如果该服务器出现故障一小时，那么在这一小时内，没有人可以进行协作或将版本更改保存到他们正在处理的任何内容中。如果中央数据库所在的硬盘损坏，并且没有保留正确的备份，那么您绝对会丢失所有内容 - 项目的整个历史记录，除了人们碰巧在本地计算机上拥有的任何单个快照。本地 VCS 也会遇到同样的问题——只要您将项目的整个历史记录集中在一个地方，您就有失去一切的风险。
1.1.3分布式版本控制系统
这就是分布式版本控制系统 （DVCS） 介入的地方。在DVCS（如Git，Mercurial，Bazaar或Darcs）中，客户端不只是签出文件的最新快照;相反，它们完全镜像存储库，包括其完整历史记录。因此，如果任何服务器死机，并且这些系统通过该服务器进行协作，则可以将任何客户机存储库复制回服务器以恢复它。每个克隆实际上是所有数据的完整备份。
此外，其中许多系统可以很好地处理他们可以使用的多个远程存储库，因此您可以在同一项目中同时以不同的方式与不同的人群协作。这允许您设置在集中式系统中无法实现的多种类型的工作流，例如分层模型。
1.2 Git 简史
与生活中的许多伟大事物一样，Git 始于一些创造性的破坏和激烈的争议。
Linux内核是一个相当大的开源软件项目。在Linux内核维护的早期（1991-2002），对软件的更改以补丁和存档文件的形式传递。2002年，Linux内核项目开始使用名为BitKeeper的专有DVCS。
2005年，开发Linux内核的社区和开发BitKeeper的商业公司之间的关系破裂，该工具的免费状态被撤销。这促使Linux开发社区（特别是Linux的创建者Linus Torvalds）根据他们在使用BitKeeper时学到的一些经验开发自己的工具。新系统的一些目标如下：
- 速度
- 简单的设计
- 强力支持非线性开发（数千个并行分支）
- 完全分布式
- 能够有效地处理像Linux内核这样的大型项目（速度和数据大小）
自 2005 年诞生以来，Git 已经发展成熟，易于使用，但保留了这些初始品质。它的速度非常快，对于大型项目非常高效，并且它有一个令人难以置信的非线性开发分支系统（请参阅 Git 分支）。
1.3 什么是 Git？
1.3.1 快照，而不是差异
Git 和任何其他 VCS（包括 Subversion 和好友）之间的主要区别在于 Git 思考其数据的方式。从概念上讲，大多数其他系统将信息存储为基于文件的更改列表。这些其他系统（CVS、Subversion、Perforce、Bazaar 等）将它们存储的信息视为一组文件，以及随时间对每个文件所做的更改，（这通常被描述为基于 delta 的版本控制）。
Git 不会以这种方式考虑或存储其数据，而是将数据存储为每个文件的基本版本的更改。Git 认为它的数据更像是一个微型文件系统的一系列快照。使用 Git，每次提交或保存项目状态时，Git 基本上都会拍摄所有文件当时的外观，并存储对该快照的引用。为了提高效率，如果文件没有更改，Git 不会再次存储该文件，只是指向它已经存储的上一个相同文件的链接。Git 将其数据视为快照流。
这是 Git 和几乎所有其他 VCS 之间的重要区别。它使 Git 重新考虑了大多数其他系统从上一代复制的版本控制的几乎所有方面。这使得 Git 更像是一个迷你文件系统，在其上构建了一些非常强大的工具，而不仅仅是一个 VCS。当我们在 Git 分支中介绍 Git 分支时，我们将探讨以这种方式考虑数据所获得的一些好处。
增量式：以文件变更列表的方式存储信息，每个版本只保存修改的那一小部分，不会存储大量重复数据，可以很好的节约服务器存储。想要得到某个历史版本时只能用当前版本的修改和各个历史版本版本的修改以及原始文件拼接得到。这类系统将其保存的信息看作是一组基本的文件和每个文件随时间逐步积累的差异。
快照流式：将数据看作是小型文件系统的一组快照，每次提commit提交更新git都会对当前版本的所有文件制作一个快照并保存这个快照的索引。为了节约内存 若文件没有修改不再重新存储该文件而是保留一个指向该文件的指针
1.3.2 几乎每个操作都是本地的
Git 中的大多数操作只需要本地文件和资源即可运行 — 通常不需要来自网络上另一台计算机的信息。如果你习惯了大多数操作都有网络延迟开销的 CVCS，那么 Git 的这一方面会让你认为速度之神赋予了 Git 超凡脱俗的力量。由于本地磁盘上都有项目的整个历史记录，因此大多数操作看起来几乎是即时的。
例如，要浏览项目的历史记录，Git 不需要去服务器获取历史记录并为您显示它——它只是直接从您的本地数据库中读取它。这意味着您几乎可以立即看到项目历史记录。如果要查看文件的当前版本与一个月前的文件之间引入的更改，Git 可以在一个月前查找文件并进行本地差异计算，而不必要求远程服务器执行此操作或从远程服务器拉取旧版本的文件在本地执行此操作。
1.3.3 Git 具有完整性
Git 中的所有内容在存储之前都经过校验和，然后由该校验和引用。这意味着在 Git 不知道的情况下不可能更改任何文件或目录的内容。此功能内置于 Git 的最低级别，是其理念不可或缺的一部分。如果没有 Git 能够检测到它，您就不会在传输过程中丢失信息或文件损坏。
Git 用于此校验和的机制称为 SHA-1 哈希。这是一个 40 个字符的字符串，由十六进制字符（0–9 和 a–f）组成，基于 Git 中文件或目录结构的内容进行计算。SHA-1 哈希如下所示：
24b9da6552252987aa493b52f8696cd6d3b00373
你会在 Git 中看到这些哈希值，因为它经常使用它们。事实上，Git 不是按文件名而是按其内容的哈希值存储其数据库中的所有内容。
哈希是一个系列的加密算法，不可逆 根据一个哈希的密文无法得到明文。
同一个哈希算法 不管输入数据的数据量有多大得到的哈希加密结果长度固定，如MD5算法 不管输入的是几K的文件还是几G的文件 得到的都是16字节的密文结果 ，常用的加密算法还有SHA1、CRC32,密文结果分别是 20字节和4字节。
哈希算法确定，输入数据有变化（哪怕一丁点） 输出结果一定有变化而且通常很大 因此可用于文件校验。
1.3.4 Git 通常只添加数据
在 Git 中执行操作时，几乎所有操作都只向 Git 数据库添加数据。很难让系统做任何不可撤销的事情或以任何方式擦除数据。与任何 VCS 一样，您可能会丢失或弄乱尚未提交的更改，但是在将快照提交到 Git 后，很难丢失，尤其是当您定期将数据库推送到另一个存储库时。
这使得使用 Git 成为一种乐趣，因为我们知道我们可以进行实验，而不会有严重搞砸事情的危险。要更深入地了解 Git 如何存储其数据以及如何恢复似乎丢失的数据，请参阅撤消操作。
1.3.5 Git 文件工作状态
现在要注意 — 如果您希望学习过程的其余部分顺利进行，以下是要记住的关于 Git 的主要事情。Git 有三种文件可以驻留的主要状态：已修改、暂存和已提交：
- 修改表示您已更改文件，但尚未将其提交到数据库。
- 暂存意味着您已将修改后的文件标记为当前版本，以进入下一个提交快照。
- “已提交”表示数据安全地存储在本地数据库中。
这将我们引向 Git 项目的三个主要部分：工作树、暂存区域和 Git 目录。
工作树是项目一个版本的单个签出。这些文件从 Git 目录中的压缩数据库中提取出来，并放置在磁盘上供您使用或修改。
暂存区域是一个文件，通常包含在 Git 目录中，用于存储有关下一次提交的内容的信息。在 Git 的说法中，它的技术名称是“索引”，但短语“暂存区域”也同样有效。
Git 目录是 Git 存储项目的元数据和对象数据库的位置。这是 Git 最重要的部分，也是从另一台计算机克隆存储库时复制的内容。
基本的 Git 工作流程如下所示：
- 修改工作树中的文件。
- 您可以有选择地暂存那些要成为下一次提交一部分的更改，这只会将这些更改添加到暂存区域。
- 执行提交，这会获取暂存区域中的文件，并将该快照永久存储到 Git 目录中。
如果文件的特定版本位于 Git 目录中，则将其视为已提交。如果它已被修改并已添加到暂存区域，则将其暂存。如果自签出以来已更改但尚未暂存，则对其进行修改。在 Git 基础知识中，你将详细了解这些状态，以及如何利用它们或完全跳过暂存部分。
1.3.6 命令行
有很多不同的方法可以使用 Git。有原始的命令行工具，并且有许多不同功能的图形用户界面。在本书中，我们将在命令行上使用 Git。首先，命令行是唯一可以运行所有 Git 命令的地方——为了简单起见，大多数 GUI 只实现了 Git 功能的一部分。如果您知道如何运行命令行版本，您可能还可以弄清楚如何运行 GUI 版本，而反之则不一定如此。此外，虽然图形客户端的选择是个人喜好的问题，但所有用户都将安装并可以使用命令行工具。
