-
1. 起步
-
2. Git 基础
-
3. Git 分支
-
4. 服务器上的 Git
- 4.1 协议
- 4.2 在服务器上部署 Git
- 4.3 生成 SSH 公钥
- 4.4 架设服务器
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 第三方托管服务
- 4.10 小结
-
5. 分布式 Git
-
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 存在的原因,为什么你应该使用它,并且你应该已经设置好以开始使用它。
关于版本控制
什么是“版本控制”,你为什么要关心它?版本控制是一个系统,它会记录文件或文件集合随时间的变化,以便你以后可以召回特定的版本。对于本书中的示例,你将使用软件源代码作为受版本控制的文件,但实际上你几乎可以使用计算机上的任何类型的文件进行版本控制。
如果你是平面设计师或网页设计师,并且想保留图像或布局的每个版本(这你肯定会想的),那么使用版本控制系统(VCS)是非常明智的。它允许你将选定的文件恢复到以前的状态,将整个项目恢复到以前的状态,比较随时间的变化,查看谁上次修改了可能导致问题的东西,谁以及何时引入了一个问题,等等。使用 VCS 通常也意味着如果你搞砸了或丢失了文件,你可以轻松恢复。此外,所有这些都只带来很少的开销。
本地版本控制系统
许多人选择的版本控制方法是将文件复制到另一个目录(如果他们聪明的话,可能是带有时间戳的目录)。这种方法非常常见,因为它非常简单,但它也极易出错。很容易忘记你所在的目录,意外地写入错误的文件或复制你不打算复制的文件。
为了解决这个问题,程序员很久以前开发了本地 VCS,它们有一个简单的数据库,用于保存受版本控制的所有文件更改。
最流行的 VCS 工具之一是一个名为 RCS 的系统,它至今仍在许多计算机上分发。RCS 的工作原理是将补丁集(即文件之间的差异)以特殊格式保存在磁盘上;然后它可以通过添加所有补丁来重新创建任何文件在任何时间点的样子。
集中式版本控制系统
人们遇到的下一个主要问题是他们需要与在其他系统上的开发人员协作。为了解决这个问题,开发了集中式版本控制系统(CVCS)。这些系统(如 CVS、Subversion 和 Perforce)有一个包含所有版本化文件的单一服务器,以及许多从该中央位置检出文件的客户端。多年来,这一直是版本控制的标准。
这种设置提供了许多优点,特别是相对于本地 VCS。例如,每个人都在一定程度上知道项目中的其他人在做什么。管理员可以对谁能做什么进行细粒度控制,并且管理 CVCS 比处理每个客户端上的本地数据库要容易得多。
然而,这种设置也有一些严重的缺点。最明显的是集中式服务器所代表的单点故障。如果该服务器停机一小时,那么在这一小时内,没有人能够协作或保存他们正在处理的任何版本化更改。如果中央数据库所在的硬盘损坏,并且没有进行适当的备份,那么你将彻底丢失所有内容——项目的整个历史记录,除了人们碰巧在本地机器上拥有的单个快照。本地 VCS 也有同样的问题——只要你将项目的整个历史记录保存在一个地方,你就有可能丢失所有内容。
分布式版本控制系统
这就是分布式版本控制系统(DVCS)的用武之地。在 DVCS(如 Git、Mercurial 或 Darcs)中,客户端不只是检出文件的最新快照;相反,它们完全镜像仓库,包括其完整的历史记录。因此,如果任何服务器发生故障,并且这些系统通过该服务器进行协作,则任何客户端仓库都可以复制回服务器以进行恢复。每个克隆实际上都是所有数据的完整备份。
此外,这些系统中的许多都很好地处理了拥有多个远程仓库的问题,因此你可以在同一个项目中同时以不同的方式与不同的人群协作。这允许你设置几种在集中式系统中不可能实现的工作流程类型,例如层次模型。