章节 ▾ 第二版

1.1 入门 - 关于版本控制

本章将介绍 Git 的入门知识。我们将首先解释版本控制工具的一些背景知识，然后介绍如何在你的系统上运行 Git，最后是如何设置 Git 来开始工作。在本章结束时，你应该能够理解 Git 的存在原因，为什么你应该使用它，并且已经准备好开始使用它。

关于版本控制

什么是“版本控制”？你为什么应该关心？版本控制是一个系统，它记录文件或一组文件随时间的变化，以便你以后可以检索特定版本。在本书的示例中，你将使用软件源代码作为被版本控制的文件，但实际上，你几乎可以用计算机上的任何类型的文件来做这件事。

如果你是一名平面设计师或网页设计师，并且想要保留图像或布局的每个版本（这肯定是你想要的），那么版本控制系统（VCS）是一个非常明智的选择。它允许你将选定的文件恢复到之前的状态，将整个项目恢复到之前的状态，比较随时间的变化，查看是谁最后修改了可能导致问题的内容，是谁引入了问题以及何时引入的，等等。使用 VCS 通常也意味着，如果你搞砸了或丢失了文件，可以轻松恢复。此外，所有这一切的开销都非常小。

本地版本控制系统

许多人选择的版本控制方法是将文件复制到另一个目录（如果他们很聪明，可能会是带时间戳的目录）。这种方法非常普遍，因为它很简单，但也很容易出错。你很容易忘记你当前在哪个目录，不小心写入错误的文件，或者复制你不想复制的文件。

为了解决这个问题，很久以前，程序员开发了本地 VCS，它有一个简单的数据库，将所有文件的更改都置于修订控制之下。

Local version control diagram
图 1. 本地版本控制示意图

最受欢迎的 VCS 工具之一是名为 RCS 的系统，该系统至今仍随许多计算机分发。 RCS 的工作方式是将补丁集（即文件之间的差异）以特殊格式保存在磁盘上；然后，通过累加所有补丁，它可以重建任何文件在任何时间点的外观。

集中式版本控制系统

人们遇到的下一个主要问题是需要与其他系统上的开发人员协作。为了解决这个问题，开发了集中式版本控制系统（CVCS）。这些系统（如 CVS、Subversion 和 Perforce）有一个包含所有版本化文件的单一服务器，以及许多从该中央位置签出文件的客户端。多年来，这一直是版本控制的标准。

Centralized version control diagram
图 2. 集中式版本控制示意图

这种设置提供了许多优势，尤其相对于本地 VCS。例如，每个人在一定程度上都知道项目中的其他人在做什么。管理员可以对谁可以做什么进行精细控制，并且管理 CVCS 比处理每个客户端上的本地数据库要容易得多。

然而，这种设置也有一些严重的缺点。最明显的是集中式服务器代表的单点故障。如果服务器宕机一个小时，那么在这一个小时内，没有人能够进行协作，也无法将版本化更改保存到他们正在处理的任何内容中。如果存储中央数据库的硬盘驱动器损坏，并且没有保留适当的备份，那么你将丢失所有内容——整个项目的历史记录，除了人们碰巧在本地机器上拥有的任何单个快照。本地 VCS 也有同样的问题——每当项目的整个历史记录集中在一个地方时，你都有丢失一切的风险。

分布式版本控制系统

这时就轮到分布式版本控制系统（DVCS）登场了。在 DVCS（如 Git、Mercurial 或 Darcs）中，客户端不仅仅是签出文件的最新快照；它们会完整地镜像存储库，包括其完整的历史记录。因此，如果任何服务器发生故障，并且这些系统通过该服务器进行协作，那么任何客户端存储库都可以被复制回服务器以进行恢复。每次克隆实际上都是所有数据的完整备份。

Distributed version control diagram
图 3. 分布式版本控制示意图

此外，这些系统中的许多都能很好地处理拥有多个远程存储库进行工作，因此你可以在同一项目中与不同的人群以不同的方式同时协作。这允许你设置集中式系统中不可能实现的几种工作流程，例如分层模型。