Git – Visual Studio 2022 与 MeGit/EGit 和 SourceTree 对比

1. 引言

Git 自 2019 年版本起就已集成到 Visual Studio IDE 中，而 2022 年版本则增加了更多功能，并正成为 Visual Studio/Microsoft 最喜欢的版本控制管理工具。本文计划对 VS2022 中的 GUI Git 工具进行基本概述。

1.1. MeGit/EGit Git GUI 客户端作为参考

我认为，并且我坚信独立的 Git GUI 客户端 MeGit/EGit [1] “做得正确”。它是一个 Git GUI 工具，但从我见过的所有 Git GUI 工具中，这个最接近“Git 的理念和术语”，我喜欢它的“外观和感觉”。因此，我将用它作为参考，并更好地展示 GUI 选项与 VS2022 GUI 的“外观和感觉”相比可能/可能的样子。当然，真正的参考应该是 Git 命令行界面，但我发现为了本文的演示目的，它太难阅读了。事实是，没有 Git GUI 能提供命令行 Git 接口为用户提供的所有选项。但事实也可能是，用户在日常工作中并不真正需要所有这些选项。例如，我多年来一直使用 TFS，并且所有的操作都通过 GUI 完成，从未用过 TFS 命令行 [2]。

1.2. VS2022 Git 理念

通过查看 VS2022 Git GUI 界面，我给人的印象是其设计者对 Git 的外观有自己的看法。他们似乎不想像 MeGit/EGit 的设计者那样，在所有细节上都紧密遵循 Git 的理念。他们似乎相信，应该尽可能多地向开发人员隐藏烦琐的 Git 细节，并简化用户界面，以便对 Git 不太了解但仅具备“版本控制”概念基本知识的开发人员可以使用它，并进行本地提交（commit）到版本控制服务器。这也许是一种明智的方法，可以通过简单的学习路径吸引许多用户/开发人员快速进入 VS2022/Git 平台。但一些资深 Git 用户可能会觉得他们缺少一些工具/选项，或者觉得 Git 没有以正确的方式进行/呈现。

1.3 SourceTree Git GUI 客户端作为参考

Atlassian SourceTree 应用程序 [3] 是另一个流行的 Git GUI 客户端。我们将并行展示其面板与 VS2022 在相同操作下的外观。我们认为 MeGit/EGit 功能更强大，并且更能遵循“Git 理念”。SourceTree 的设计者，与 VS2022 的设计者类似，选择了隐藏部分“Git 内部信息”，如 HEAD 和 Refs。尽管如此，他们展示的信息比 VS2022 要多。

1.4 Git 不易于学习

我确信许多开发人员将尝试通过玩弄 VS2022 的 Git GUI 选项来“ hack 方式进入 Git”。尤其是那些来自其他版本控制系统（如 TFS）的开发人员。并且在一定程度上会奏效，特别是由于 VS2022 有意隐藏了一些 Git 概念，例如文件的暂存（典型的 TFS 用户会问什么是暂存，为什么我需要它？）。但我的建议是，迟早你需要阅读一些 Git 书籍，因为 Git 有自己的术语和工作理念，如果你遇到 Git 问题，像往常一样，你需要确切地知道你在做什么以及解决问题的正确方法。如果你喜欢通过“hack GUI 工具”来学习，我学习 Git 的建议是尝试玩弄 MeGit/EGit，因为这样你将看到更多 VS2022 有意隐藏的细节。

1.5 这不是 Git 教程

本文并非意在成为 Git 教程。目标读者是具有一定 Git 知识的开发人员，他们想了解 Git 在 VS2022 IDE 中的现状。

2. VS2022 vs MeGit

2.1. 测试方法

我们将使用四个工具（VS2022、MeGIt、SourceTree 和 GitBash）查看同一个 Git 仓库。

我们创建了一个简单的 C# 应用程序项目，并选择了 GitHub 作为远程仓库。

我测试时使用的 Visual Studio 版本是

2.2. 查看仓库提交历史记录

一个非常基本且重要的功能是使用户能够查看其仓库的内容。

2.2.1. GitBash 的历史记录

Git 命令 `git log` 将提供所有提交的日志。

这是当前分支“master”的所有提交。

这是所有分支的所有提交，其中包含当前分支“master”。

这是 GitBash 可以生成的“图表”，显示所有分支的所有提交，其中包含当前分支“master”。

2.2.2. MeGit 的历史记录

这是 MeGit 生成的相应图表。这是一个很好的图形化展示。

它看起来类似于 GitBash 生成的“图表”。请注意，GitBash 图表包含一项额外信息，即“stash”发生的位置，提交 ac95254。MeGit 可以显示该位置，但仅在请求时（点击特定 stash 时）。

2.2.3. VS2022 的历史记录

尽我所能，我在 VS2022 中找到了三个历史图表，而且所有都比命令行 Git 图表差。似乎他们并不真正关心实现它。这里发生的是 VS2022 的 History 面板正在过滤并仅显示与当前选定分支相关的提交。

第一个，对于相同的仓库设置，当前分支为“master”，如下所示：

他们提供了一个更简单的版本，没有其他分支：

还有一个版本，显示了分支引用：

我的观点是，VS2022 的历史图表不如 MeGit 的历史图表，并且功能强大的用户会发现此类图表很有用。它们提供了仓库更改的良好概览。

我在网上看到有人评论：为什么你需要一个花哨的图表？对我来说，答案很简单：它被称为图形用户界面（GRAPHICAL user interface），所以拥有一个与 MeGit 历史图表相媲美的优质图表将是很棒的。

遗憾的是，请注意 VS2022 在图表中*不*显示 HEAD 引用的位置，而 GitBash 和 MeGit 都清楚地显示 HEAD 引用。似乎 VS 设计者认为，像 HEAD 引用这样的 Git 术语需要对用户隐藏。我不确定长期有效地使用 Git 是否真的可能，而不了解 HEAD 引用的含义。

2.2.2. SourceTree 的历史记录

这是 SourceTree 生成的相应图表。这是一个很好的图形化展示。

但同样，SourceTree 的设计者决定隐藏 HEAD 和 Refs 等概念，以免用户看到。

2.3. 查看分支、标签、引用

2.3.1. MeGit 中的分支、标签、引用

项目/仓库的分支、标签和引用可以轻松查看

请注意当前检出的分支“master”是如何标记的。您还可以看到 HEAD ref 指向本地“master”分支的尖端和提交 ec56b90。

要检出分支“Feature1”，您需要右键单击所需的分支并从上下文菜单中选择该选项。

2.3.2. VS2022 中的分支、标签、引用

在 VS2022 中，显示的信息更为朴实。

据我所知，标签列表本身不可用，应用标签只能在历史图表中看到。引用列表也显然不可用，设计者认为它太底层且不需要，因此隐藏了该信息。

请注意，当前检出的分支“master”如何粗体显示。此外，可以在右下角看到当前检出的分支。

要检出分支“Feature1”，您需要右键单击所需的分支并从上下文菜单中选择该选项。

您也可以从右下角的弹出菜单执行分支检出。

2.3.3. SourceTree 中的分支、标签、引用

项目/仓库的分支、标签可以轻松查看。但 GUI 不显示引用。同样，该工具的设计者决定向用户隐藏“Git 细节”。

请注意当前检出的分支“master”如何粗体显示。

要检出分支“Feature1”，您需要右键单击所需的分支并从上下文菜单中选择该选项。

2.4. 查看分离 HEAD 状态

进入“分离 HEAD”（Detached HEAD）状态并不困难。只需检出某个非分支尖端的提交，然后提交更多更改即可。让我们看看这种状态是如何呈现的。

2.4.1. MeGit 中的分离 HEAD

这是分离 HEAD 状态在 History 面板中的样子。

如您所见，HEAD 指向提交 40c21ff，并且*不在*任何分支尖端。用 Git 的术语来说，该提交处于分离 HEAD 状态。在分支概览面板中，其显示如下：

请注意，*没有*分支被标记为选中，并且 HEAD 引用包含该提交 40c21ff 的 ID 值。

2.4.2. VS2022 中的分离 HEAD

我们将从 VS2022 查看相同的仓库情况。这是 Branches 面板中的样子：

请注意，没有分支被粗体显示，这意味着没有分支被检出。

此外，在右下角标记了分离 HEAD 状态：

可以看到，VS2022 中避免了提及 HEAD 引用，尽管这“直观上并不易于理解”仓库中发生了什么以及如何解决“分离 HEAD”状态。这就是为什么我认为一个人需要真正了解 Git，而工具通过隐藏 Git 概念并不能提供帮助。

2.4.3. SourceTree 中的分离 HEAD

这是分离 HEAD 状态在 History 面板中的样子。

如您所见，HEAD 指向最后一个提交，并且*不在*任何分支尖端。您可以在下面的面板中看到提交哈希，它是 40c21ff。用 Git 的术语来说，该提交处于分离 HEAD 状态。有趣的是，他们突然展示了叫做“HEAD”的东西，而之前他们一直在应用程序中隐藏这种概念。

在分支概览面板中，其显示如下：

请注意，*没有*分支被标记为选中。

2.4.4. 故意创建“悬空提交”（Dangling Commit）

假设我们决定通过检出“master”分支来解决“分离 HEAD”状态，而将我们的新提交 40c21ff 悬空。这样的提交无法从任何 Ref 访问，并且将不再显示在 History 中。

2.4.5. MeGit 中恢复悬空提交/分离 HEAD

现在 History 和 Branches 显示已检出的分支“master”，并且在任何地方都没有提及提交 40c21ff。

如果我们犯了错误，现在想恢复那个悬空的提交 40c21ff 怎么办？这是可能的，我们仍然可以在 Reflog 面板中找到它：

然后我们可以右键单击它并选择恢复它的菜单选项：

现在我们又回到了检出该提交 40c21ff 的情况，并且现在可以做任何我们想做的事情。

2.4.6. VS2022 中恢复悬空提交/分离 HEAD

这是 VS2022 中相同情况的样子：

现在 History 和 Branches 显示已检出的分支“master”，并且在任何地方都没有提及提交 40c21ff。我们可以恢复提交 40c21ff 吗？问题是，VS2022 没有 Reflog 面板。

严格来说，那个提交 40c21ff 仍然在仓库中，只是无法从 VS2022 GUI 访问。
对于功能强大的用户来说，这可能是一个问题，他们可能需要求助于 VS2022 以外的工具来执行他们想要/需要的操作。VS2022 的设计者认为这种情况足够罕见，以至于普通用户永远不需要处理这种情况。

2.4.7 SourceTree 中恢复悬空提交/分离 HEAD

现在 SourceTree 中的情况如下：现在 History 和 Branches 显示已检出的分支“master”，并且在任何地方都没有提及提交 40c21ff。

我们可以恢复提交 40c21ff 吗？问题是，SourceTree 没有 Reflog 面板。但是，它提供了一个指向 GitBash 的快捷方式，因此我们可以从命令行获取我们需要的信息，即提交哈希：

所以我们可以从命令行运行“git reflog”并获得所需的哈希：

然后，当我们有了悬空提交的哈希时，通过一点变通，我们可以恢复该提交。我们将显式创建一个包含该提交的新分支。

一旦我们检出了该提交 40c21ff，这次作为新分支的一部分，我们可以对其进行任何我们想做的事情。

2.5. 查看未暂存文件/暂存文件/提交面板

Git GUI 的主要功能之一是将工作提交到仓库。

2.5.1. MeGit 中的未暂存文件/暂存文件/提交面板

MeGit 遵循 Git 理念，为未暂存和已暂存文件提供单独的表单。

在这里，您可以看到文件 ClassA.cs 已被修改，并且 Git 在未暂存文件（“Working directory changes”）表单中列出了更改：

但是，要进行提交（并非“Commit”按钮被禁用），您需要使用“加号”并将更改添加到 Staged files 表单，然后您就可以将更改提交到仓库了。

2.5.2. VS2022 中的未暂存文件/暂存文件/提交面板

VS2022 默认的提交对话框显示了直接从“Working directory changes”（未暂存文件）提交文件的选项：

根据 Git 规则，这实际上是可以的，因为有这样的命令行 Git 命令。这类似于运行“git commit -am "<commit message>”。

如果您想查看“Staged files”表单并选择要暂存和提交的文件，您需要使用“加号”并将需要提交的文件添加到 Staged：

现在提交对话框看起来像 MeGit 的对话框了。

VS2022 的设计者决定“走捷径”，直接从“Working directory changes”表单显示提交。
常见问题是：为什么我需要先暂存文件？答案很简单：您不需要，这是一个选项，用于处理您更改了 5 个文件但只想提交其中 3 个文件的情况。您可以通过暂存这 3 个文件并仅提交已暂存文件来解决这种情况。

2.5.3. SourceTree 中的未暂存文件/暂存文件/提交面板

SourceTree 遵循 Git 理念，为未暂存和已暂存文件提供单独的表单。

在这里，您可以看到文件 ClassA.cs 已被修改，并且 Git 在未暂存文件（“Working directory changes”）表单中列出了更改：

但是，要进行提交（并非“Commit”按钮被禁用），您需要使用“Stage Selected button”并将更改添加到 Staged files 表单，然后您就可以将更改提交到仓库了。

2.6. 查看 Stashes

两个工具都提供了用于查看 stash 的漂亮面板。

2.6.1. MeGit 中的 Stashes

仓库中所有 stash 的列表

然后我们选择了一个特定的 stash，索引为 [0] 的 Stash。然后我们可以看到该 stash 的详细信息：

创建 stash 的历史位置

关于该 stash 的详细信息

显示 stash 更改的文件差异

2.6.2. VS2022 中的 Stashes

仓库中所有 stash 的列表

然后我们选择了一个特定的 stash，索引为 [0] 的 Stash。然后我们可以看到该 stash 的详细信息：

关于该 stash 的详细信息

显示 stash 更改的文件差异

VS2022 不包含在历史图表上显示 stash 创建位置的选项。看起来 VS2022 团队的某个人讨厌 Git 历史图表。

有人可能会问：为什么你想在图表上看到这些信息？对我来说，答案很简单：它被称为图形用户界面（GRAPHICAL user interface），所以希望也能在图表上看到这些信息。

2.6.3. SourceTree 中的 Stashes

仓库中所有 stash 的列表

然后我们选择了一个特定的 stash，索引为 [0] 的 Stash。

显示 stash 更改的文件差异

2.7. 查看 Blame

2.7.1. MeGit 中的 Blame

很难找到 Blame 功能，这次 MeGit 没有使用 Git 术语“Blame”，而是使用了“Revision information”，因此很难找到。它看起来不错：

您可以看到我们查看了文件 Program.cs 的第 12 行。上次修改它的作者是“MarkPelf”，在 commit cef7440 中，下面您可以看到关于该提交的高级信息，包括历史图表。

您还可以看到 commit cef7440 的文件 diff。

2.7.2. VS2022 中的 Blame

对于相同的情况（文件 Program.cs 和第 12 行），VS2022 最初显示的信息较少，但您可以右键单击以获取有关谁以及在哪个提交中最后更改该行的更多信息：

Blame 屏幕

右键单击感兴趣的代码行

commit cef7440 的提交详情

commit cef7440 的历史图表

2.7.3 SourceTree 中的 Blame

对于相同的情况（文件 Program.cs 和第 12 行），SourceTree 最初显示的信息较少，但您可以右键单击以获取更多信息。

右键单击感兴趣的代码行

commit cef7440 的提交详情

3. 结论

在本文中，我们简要概述了 VS2022 Git GUI IDE 集成，并将其与 Git GUI 客户端 MeGit/EGit 和 SourceTree 进行了比较。我们展示了 MeGit 具有更丰富的 UI，并且更紧密地遵循“Git 理念和术语”。我们展示了 VS2022 采取了简化 Git UI 的方法，并且许多 Git 内部信息对用户是隐藏的。

好消息是，这将吸引更多开发人员更快地使用 Git 平台，并鼓励他们迁移到 Git，因为 UI 简单且学习路径容易。坏消息是，一些重要的 Git 概念（如 Refs HEAD 等）对用户隐藏，并且一些 Git 选项被故意限制。Git 的高级用户可能需要其他 Git 工具，无论是 GitBash 还是其他 Git GUI 客户端（MeGit/EGit [1]、Sourcetree [3]），以更好地了解其仓库并执行 VS2022 Git GUI 不支持的复杂操作。

但毫无疑问，将 Git 集成到 VS2022 IDE 中将为 Git 版本控制系统带来更高的普及度。

4. 参考资料

• [1] https://github.com/eclipsesource/megit
• [2] https://docs.microsoft.com/en-us/azure/devops/repos/tfvc/use-team-foundation-version-control-commands?view=azure-devops
• [3] https://sourcetreeapp.com/

5. 历史记录

• 2022 年 8 月 4 日：初始版本