Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
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 形成鲜明对比，新分支通常较复杂且很少被创建。 第一步是使用以下命令切换到新分支：
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 历史记录的一个示例，该历史记录更类似于团队中活动开发中的代码。 有三个人在同一时间将提交从自己的分支合并到主分支中。
现在，你已了解分支和合并如何创建图形的形状，这不应该太可怕了！