了解 Git 历史

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Git 将历史记录存储为整个存储库的快照图（称为提交）。 每个提交还包含指向一个或多个先前提交的指针。 提交可以有多个父项，并创建类似于图形而不是直线的历史记录。 此历史记录差异非常重要，也是用户发现 Git 令人困惑的主要原因。

注意

如果在 Git 历史记录中找不到自己所做的已知更改，请在 Git 丢失我的更改：查看 Git 的历史记录简化中详细了解 Git 历史记录简化的工作原理。

提交历史记录基础知识

从简单的历史记录示例开始：一个包含 3 个线性提交的存储库。

提交 A 是提交 B 的父级，提交 B 是提交 C 的父级。此历史记录看起来与 CVCS 非常相似。 指向提交 C 的箭头是一个分支。 它被命名为 main，因为这是 Git 存储库中主线分支的默认名称。 分支是指向特定提交的指针，这就是分支在 Git 中如此轻量级和简单的原因。

与 CVCS 相比，Git 的一个主要区别是拥有自己的存储库的完整副本。 我需要通过从远程存储库获取最新提交，使本地存储库与远程存储库保持同步。 为此，我将使用以下命令拉取主分支：

git pull origin main

这会将远程存储库的 main 分支（默认称为 origin）中的所有提交复制（“拉取”）到本地存储库的 main 分支。 拉取操作复制了一个新提交，本地存储库中的 main 分支现在指向该新提交。

了解分支历史记录

现在，我想对代码进行更改。 拥有多个活动分支是很常见的，可以在其中并行处理不同的功能。 这与 CVCS 形成鲜明对比，CVCS 新分支繁多且很少创建。 第一步是使用以下命令签出到新分支：

git checkout -b cool-new-feature

下面是结合了两个命令的快捷方式：用于创建分支的 git branch cool-new-feature，后跟用于开始在分支中工作的 git checkout cool-new-feature。

两个分支现在指向同一个提交。 我将在两个新提交 E 和 F 中对 cool-new-feature 分支进行一些更改。

我的提交可通过 cool-new-feature 分支访问，因为我在该分支中创建了这些提交。 我完成了我的功能，并想要将其合并到 main 中。 为此，我将使用以下命令：

git merge cool-feature main

合并时，历史记录的图形结构变为可见。 当我将我的分支合并到另一个分支时，Git 将创建新提交。 这是合并提交。 由于没有冲突，因此此合并提交中不包含任何更改。 如果存在冲突，合并提交将包括解决这些冲突所需的更改。

现实世界中的历史记录

下面是更类似于团队中积极开发的代码的 Git 历史记录示例。 三人大约在同一时间将他们自己分支中的提交合并到主分支。

现在，你了解了分支和合并如何创建图形的形状，这应该不会太可怕！