-
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，它有一个简单的数据库，可以保留对版本控制下文件的更改。
最流行的版本控制系统工具之一是名为 RCS 的系统，它至今仍与许多计算机一起分发。 RCS 的工作原理是将补丁集（即文件之间的差异）以特殊格式保存在磁盘上；然后，它可以通过累加所有补丁来重新创建任何文件在任何时间点的状态。
集中式版本控制系统
人们遇到的下一个主要问题是需要与其他系统的开发人员协作。为了解决这个问题，开发了集中式版本控制系统 (CVCS)。这些系统（例如 CVS、Subversion 和 Perforce）有一个包含所有版本化文件的单个服务器，以及许多从该中央位置检出文件的客户端。多年来，这已成为版本控制的标准。
这种设置提供了许多优势，尤其是在本地 VCS 之上。例如，每个人都在一定程度上知道项目中其他每个人在做什么。管理员可以对谁可以做什么进行细粒度的控制，并且管理 CVCS 比处理每个客户端上的本地数据库要容易得多。
但是，这种设置也有一些严重的缺点。最明显的是集中式服务器代表的单点故障。如果该服务器宕机一小时，那么在这段时间内，任何人都无法进行协作或保存其正在处理的任何内容的版本化更改。如果中央数据库所在的硬盘损坏，并且没有保留适当的备份，那么您将彻底丢失所有内容——项目的整个历史记录，除了人们碰巧在本地机器上拥有的任何单个快照之外。
分布式版本控制系统
这就是分布式版本控制系统 (DVCS) 介入的地方。在 DVCS（如 Git、Mercurial 或 Darcs）中，客户端不仅检出文件的最新快照；而是完全镜像存储库，包括其完整历史记录。因此，如果任何服务器宕机，并且这些系统通过该服务器进行协作，则可以将任何客户端存储库复制回服务器以恢复它。每个克隆实际上都是所有数据的完整备份。
此外，许多这些系统都能很好地处理多个远程存储库，因此您可以在同一个项目中以不同的方式与不同的人员群体同时协作。这允许您设置集中式系统中无法实现的几种类型的流程，例如分层模型。
