-
A1. 附录 A: Git 在其他环境
- A1.1 图形界面
- A1.2 Visual Studio 中的 Git
- A1.3 Visual Studio Code 中的 Git
- A1.4 IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine 中的 Git
- A1.5 Sublime Text 中的 Git
- A1.6 Bash 中的 Git
- A1.7 Zsh 中的 Git
- A1.8 PowerShell 中的 Git
- A1.9 小结
-
A2. 附录 B: 在应用程序中嵌入 Git
-
A3. 附录 C: Git 命令
1.1 入门 - 关于版本控制
本章将介绍 Git 的入门知识。我们将首先解释版本控制工具的一些背景知识，然后介绍如何在您的系统上运行 Git，最后是如何设置 Git 以开始工作。在本章结束时，您应该理解 Git 存在的原因、为什么要使用它，并且您应该已经做好了开始使用的所有准备。
关于版本控制
什么是“版本控制”，你为什么要关心它？版本控制是一个系统，它记录文件或文件集随时间的变化，以便您以后可以召回特定版本。在本书的示例中，您将使用软件源代码作为受版本控制的文件，但实际上，您可以使用计算机上的几乎任何类型的文件进行此操作。
如果你是一名平面设计师或网页设计师，并且想保留图像或布局的每个版本（这当然是你最希望的），那么使用版本控制系统（VCS）是非常明智的选择。它允许您将选定的文件恢复到以前的状态，将整个项目恢复到以前的状态，比较随时间的变化，查看谁最后修改了可能导致问题的内容，谁在何时引入了问题等等。使用 VCS 通常也意味着如果你搞砸了或丢失了文件，你可以轻松恢复。此外，所有这些都只需要很少的开销。
本地版本控制系统
许多人选择的版本控制方法是将文件复制到另一个目录（如果他们够聪明，可能会是一个带有时间戳的目录）。这种方法非常普遍，因为它如此简单，但也极易出错。很容易忘记你所在的目录，然后意外地写入错误的文件或覆盖你不想覆盖的文件。
为了解决这个问题，程序员们很早以前就开发了本地 VCS，它们有一个简单的数据库，用于保存受版本控制文件的所有更改。
最流行的 VCS 工具之一是名为 RCS 的系统，它至今仍随许多计算机分发。RCS 的工作原理是将补丁集（即文件之间的差异）以特殊格式保存在磁盘上；然后它可以通过累加所有补丁来重建任何文件在任何时间点的样子。
集中式版本控制系统
人们遇到的下一个主要问题是他们需要与在其他系统上的开发人员协作。为了解决这个问题，集中式版本控制系统（CVCS）应运而生。这些系统（如 CVS、Subversion 和 Perforce）都有一个包含所有版本化文件的中央服务器，以及许多从该中央位置检出文件的客户端。多年来，这一直是版本控制的标准。
这种设置提供了许多优势，特别是相对于本地 VCS 而言。例如，项目中的每个人都在一定程度上知道其他人在做什么。管理员可以对谁能做什么进行细粒度控制，并且管理 CVCS 远比处理每个客户端上的本地数据库容易。
然而，这种设置也有一些严重的缺点。最明显的是集中式服务器代表的单点故障。如果该服务器宕机一小时，那么在这期间，没有人能够进行协作或保存他们正在进行的任何版本化更改。如果中央数据库所在的硬盘损坏，并且没有妥善的备份，您将失去一切——除了人们本地机器上可能有的单个快照之外，项目的整个历史都将丢失。本地 VCS 也存在同样的问题——只要您将项目的整个历史存储在一个地方，您就面临失去一切的风险。
分布式版本控制系统
这就是分布式版本控制系统（DVCS）发挥作用的地方。在 DVCS（如 Git、Mercurial 或 Darcs）中，客户端不仅检出文件的最新快照；相反，它们会完整地镜像整个仓库，包括其完整的历史记录。因此，如果任何服务器发生故障，并且这些系统是通过该服务器进行协作的，那么任何客户端仓库都可以被复制回服务器以进行恢复。每个克隆都是所有数据的完整备份。
此外，许多此类系统能够很好地处理多个远程仓库，因此您可以在同一个项目中同时以不同方式与不同人群协作。这使您能够设置几种在集中式系统中不可能实现的工作流程类型，例如分层模型。
