在我撰写的 Git DevOps 文章 (msdn.com/magazine/mt767697) 中，我介绍了 Git 版本控制系统 (VCS) 与可能已经很熟悉的集中式 VCS 的区别。然后，atv，我演示了如何在 Visual Studio 中使用 Git 工具完成一些 Git 任务。在本文中，我将汇总 Git 在新发布的 Visual Studio 2017 IDE 中的运作方式的相关变化，并介绍 Git 存储库在文件系统中的实现方式。之后，我将探究数据存储的拓扑和各种存储对象的结构和内容。最后，我将对 Git 分支进行低级别解释，以阐明我的观点，即希望大家能够理解我将在近期发表的文章中介绍的更高级 Git 操作。

注意： 在本文中，我没有使用服务器或远程方案。我探究的是纯本地方案，可以在安装了 Visual Studio 2017 和 Git for Windows (G4W) 的任何一台 Windows 计算机（已连接或未连接 Internet/网络连接）上进行操作。本文介绍了 Git 内部源代码。阅读本文的前提是，熟悉 Visual Studio Git 工具以及 Git 基本操作和概念。

Git 不仅是指包含版本控制数据存储的存储库，也是指处理管理命令的引擎： 底层命令执行低级别操作；高层命令以类似于宏的方式捆绑底层命令，从而宏观调用，简化操作。掌握 Git 后，你会发现一些任务需要用到这些命令（我将在本文中使用其中一些命令），并且需要使用命令行接口 (CLI) 来调用这些命令。遗憾的是，Visual Studio 2017 不再安装 Git CLI，因为它使用的新 Git 引擎 MinGit 并不提供 Git CLI。与 G4W 2.10 一同发布的 MinGit（“最简 Git”）是可移植的简化功能集 API，专为需要与 Git 存储库进行交互的 Windows 应用程序而设计。G4W 乃至 MinGit 都是官方 Git 开放源代码项目的分支。也就是说，它们都继承了官方 Git 修补程序和更新程序（只要已发布），并确保 Visual Studio 可以执行同样的操作。

若要访问 Git CLI（并继续和我一起操作），建议安装完整的 G4W 程序包。虽然有其他 Git CLI/GUI 工具选项，但 G4W（作为 MinGit 的官方父级引擎）是明智之选，特别是因为它与 MinGit 共享配置文件。若要获取最新的 G4W 安装程序，请访问官方网站来源 (git-scm.com) 的“下载”部分。运行安装程序，并选中“Git Bash Here”复选框（创建 Git 命令提示符窗口）和“Git GUI Here”复选框（创建 Git GUI 窗口）。这样一来，便可以在 Windows 资源管理器中轻松右键单击文件夹，然后对当前文件夹选择这两个选项之一（Git Bash 中的“Bash”是指 Bourne Again Shell，在 G4W 的 Unix shell 中表示 Git CLI）。下一步，选择“通过 Windows 命令提示符使用 Git”，这会将环境配置为可以在 Visual Studio 程序包管理器控制台 (Windows PowerShell) 或命令提示符窗口中轻松运行 Git 命令。

如果使用我在本文中建议的选项安装 G4W（见图 1），通信路径将会在与 Git 存储库通信时生效： Visual Studio 2017 使用 MinGit API，而 PowerShell 和命令提示符会话则使用 G4W CLI，这是与 Git 存储库通信的不同通信路径。虽然 MinGit 和 G4W 是不同的通信终结点，但都派生自官方 Git 源代码，并共享配置文件。请注意，发出的高层命令会先被转换成底层命令，然后再由 CLI 进行处理。重要的是了解 Git 专家通常会（有时完全依靠）向 CLI 发出裸机 Git 底层命令，因为这样做是管理、查询和更新 Git 存储库的最直接方法，也是最低级别方法。与低级别的底层命令相比，Visual Studio IDE 公开的更高级别高层命令和 Git 操作也可以更新 Git 存储库，但具体方式始终不太清楚，特别是因为高层命令经常接受在调用时行为发生变化的选项。我得出的结论是，熟悉 Git 底层命令对充分利用 Git 功能必不可少。正因为此，我强烈建议同时安装 G4W 和 Visual Studio 2017。（若要详细了解 Git 底层命令和高层命令，请访问 git-scm.com/docs。）

图 1：MinGit API 和 Git for Windows 命令行接口的往来通信路径

Visual Studio 开发者在迁移到 Git 时很自然就会试图利用 VCS 的现有知识，如 Team Foundation Server (TFS)。用于描述这两个系统中的操作的术语和概念（如签出/签入代码，合并、分支等）的确存在重叠。不过，如果因此假设类似词汇指代的基础操作也类似，是十足错误和危险的想法。这是因为分散式 Git VCS 存储和跟踪文件的方式，以及其实现熟悉的版本控制功能的方式是根本不同的。简单来说，在迁移到 Git 时，最佳做法可能是完全忘掉关于集中式 VCS 所掌握的一切知识，然后重新开始学习。