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

1.2. VS2022 Git理念

通过查看VS2022 Git Gui界面，我的印象是它的设计师对Git应该是什么样子有自己的看法。他们似乎不想在所有细节上都严格遵循Git哲学，例如MeGit/EGit的设计师所做的那样。看起来他们认为应该尽可能多地对开发人员隐藏令人讨厌的Git细节，并简化用户界面，以便不了解Git但只是“版本控制”概念的基本知识的开发人员可以使用它并在本地签入（提交）他们的工作和版本控制服务器。也许这是一种聪明的方法，由于简单的学习路径，它将为许多用户/开发人员带来快速进入VS2022/Git平台。但是一些强大的Git用户可能会觉得他们缺少一些工具/选项，或者可能觉得Git没有以正确的方式完成/呈现。

1.3 SourceTree Git GUI客户端作为参考

Atlassian SourceTree应用程序[3]是另一个流行的Git Gui客户端。我们将同时展示其面板与VS2022在相同操作下的外观。我们认为MeGit/EGit更强大，更好地遵循“Git哲学”的工作。与VS2022类似的SourceTree设计人员选择隐藏部分“Git内部”，如HEAD和Refs信息。不过，他们比VS2022展示得更多。

1.4 Git不是学习的直观工具

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

1.5 这不是Git教程

这不是一个Git教程。目标受众是具有一定Git知识的开发人员，他们希望了解Git现在在VS2022 IDE中的外观。

2. VS2022与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可以显示该位置，但只能根据请求（单击特定存储时）显示该位置。

2.2.3. VS2022的历史

尽我最大的努力，我在VS2022中找到了三个历史图，它们甚至都不如命令行Git图。看来他们并不真正关心实现它。这里发生的事情是VS2022历史记录面板正在过滤并显示仅与当前所选分支相关的提交。

第一个，对于相同的存储库设置，使用当前分支“master”是：

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

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

我的观点是VS2022历史图不如MeGit历史图，高级用户可以发现这样的图很有用。它们很好地概述了对存储库的更改。

我在网上看到有人评论：为什么需要一个花哨的图表？对我来说，答案很简单：它被称为图形用户界面，所以有一个高质量的图表可以与例如MeGit历史图竞争会很好。

可悲的是，请注意，VS2022没有显示在HEAD引用的图形位置中，而GitBash和MeGit都清楚地显示了HEAD引用。VS设计师似乎得出结论，像HEAD引用这样的Git术语需要对用户隐藏。我不确定是否真的有可能在不知道什么是HEAD引用的情况下长时间胜任使用Git。

2.2.4. SourceTree的历史

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

但同样，SourceTree设计师决定躲避像HEAD和Refs这样的用户概念。

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

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

可以轻松看到项目/存储库的分支、标签和引用：

请注意当前签出的分支“master”是如何标记的。此外，您可以看到HEAD ref指向本地“master”分支提示并提交ec56b90。

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

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

在VS2022中，显示的信息更加谦卑：

据我所知，标签列表本身不可用，应用的标签只能在历史图表中看到。Refs列表也不可用，显然，设计师认为这太低了，不需要，所以他们隐藏了这些信息。

请注意当前签出的分支“master”是如何加粗的。此外，当前签出的分支可以在右下角看到。

为了签出分支“Feature1”，您需要右键单击所需的分支，然后从上下文菜单中选择选项。

而且，您也可以从右下角的弹出菜单中执行分支签出：

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

可以轻松看到项目/存储库的分支、标签。但GUI不显示引用。该工具的设计者再次决定向用户隐藏“Git详细信息”。

请注意当前签出的分支“master”是如何加粗的。

为了签出分支“Feature1”，您需要右键单击所需的分支，然后从上下文菜单中选择选项。

2.4. 查看分离的HEAD状态

进入“分离的HEAD”状态并不难。您只需要签出一些不是分支提示的提交，然后提交更多更改。让我们看看这种状态是如何呈现的。

2.4.1. MeGit中的分离HEAD

以下是“已分离”HEAD状态在“历史记录”面板中的外观：

如您所见，HEAD指向提交40c21ff并且不在任何分支提示上。在Git术语中，该提交处于分离HEAD状态。在分支概述面板中，如下所示：

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

2.4.2. VS2022中的分离HEAD

我们将从VS2022中查看相同的存储库情况。下面是它在“分支”面板中的外观：

请注意，没有分支是粗体的，这意味着没有分支被签出。

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

可以看出，避免在VS2022中提及HEAD ref，尽管它绝对不是“直观地不言自明”存储库发生了什么以及如何解决“分离的HEAD”状态。这就是为什么我认为一个人需要真正了解Git并且工具通过隐藏Git概念无济于事的原因。

2.4.3. SourceTree中的分离HEAD

以下是“已分离”HEAD状态在“历史记录”面板中的外观：

如您所见，HEAD指向最后一个提交，并且不在任何分支提示上。您可以在下面的面板中看到提交哈希，它是40c21ff。在Git术语中，该提交处于“已分离”HEAD状态。有趣的是，他们突然显示一个名为“HEAD”的东西，并且在他们将此类概念隐藏在应用程序中之前。

在分支概述面板中，如下所示。

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

2.4.4. 故意创建“悬空提交”

假设我们决定通过检查“master”分支并让我们的新提交40c21ff悬而未决来解决“分离的HEAD”状态。这样的提交无法从任何Ref访问，也不会再显示在历史记录中。

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

现在历史记录和分支显示签出的分支“master”，并且在任何地方都没有提到提交40c21ff。

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

然后我们可以右键单击它并获取菜单选项来恢复它：

在这里，我们再次处于检查提交40c21ff的情况，我们现在可以做任何我们想做的事情。

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

以下是VS2022中相同情况的样子：

现在历史记录和分支显示签出的分支“master”，并且在任何地方都没有提到提交40c21ff。我们可以恢复提交40c21ff吗？问题是，VS2022没有Reflog面板。

准确地说，提交40c21ff仍在存储库中，只是无法从VS2022 GUI访问。

对于高级用户来说，这可能是一个问题，他可能需要向VS2022以外的其他工具提供资源来执行他想要/需要的操作。VS2022设计师认为这种情况很少见，因此普通用户永远不需要处理这种情况。

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

这是SourceTree现在的情况。现在历史记录和分支显示签出的分支“master”，并且在任何地方都没有提到提交40c21ff。

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

因此，我们可以从命令行运行“git reflog”并获取我们需要的哈希：

然后，当我们有一个悬空提交的哈希值时，通过一些解决方法，我们可以恢复该提交。我们将显式创建一个包含该提交的新分支。

一旦我们签出了提交40c21ff，这次作为新分支的一部分，我们可以随心所欲地使用它。

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

Git Gui的主要功能之一是将工作提交到存储库中。

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

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

在这里，您可以看到文件 ClassA.cs 发生了更改并且文件Git列出了未暂存文件形式的更改（“工作目录更改”）形式：

但是为了提交（不是禁用了“提交”按钮），您需要使用该“加号”并将更改添加到暂存文件表单，然后您可以将更改提交到存储库。

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

VS2022作为默认提交对话框显示直接从“工作目录更改”（未暂存文件）提交文件的选项：

根据Git规则，这实际上都很好，因为有这样一个命令行Git命令。这类似于运行“git commit -am ”<commit message>”。

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

现在，提交对话框类似于MeGit对话框。

VS2022设计人员决定通过显示“工作目录更改”表单中的直接提交来“偷工减料”。
通常的问题是：为什么我需要先暂存文件？答案很简单：您不需要，这是当您更改5个文件并只想提交其中3个文件时的一种选择。您可以通过暂存这3个文件并仅提交暂存文件来解决这种情况。

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

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

在这里，您可以看到文件 ClassA .cs发生了更改并且文件Git列出了未暂存文件形式的更改（“工作目录更改”）形式：

但是，为了提交（不是禁用“提交”按钮），您需要使用该“暂存选定”按钮并将更改添加到暂存文件表单，然后您可以将更改提交到存储库。

2.6. 查看存储

这两种工具都提供了漂亮的面板来查看存储。

2.6.1. MeGit 中的存储

存储库中所有存储的列表：

然后我们选择一个特定的存储，带有索引[0]的存储。然后我们可以看到有关该存储的详细信息：

历史上藏匿的位置：

有关该存储的详细信息：

显示存储更改的文件差异：

2.6.2. VS2022中的存储

存储库中所有存储的列表：

然后我们选择一个特定的存储，带有索引[0]的存储。然后我们可以看到有关该存储的详细信息：

有关该存储的详细信息：

显示存储更改的文件差异：

VS2022不包括在历史图表位置上显示存储位置的选项。看起来VS2022团队中的某个人讨厌Git历史图。

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

2.6.3. SourceTree中的存储

存储库中所有存储的列表：

然后我们选择一个特定的存储，带有索引[0]的存储。

显示存储更改的文件差异：

2.7. 查看Blame

2.7.1. MeGit中的Blame

很难找到一点Blame功能，这次MeGit使用的不是Git术语“Blame”，而是“修订信息”，这就是为什么很难找到它的原因。它看起来不错：

您可以看到我们查看了文件Program.cs和第12行。最后一次触摸它是由作者“MarkPelf”，在提交cef7440及以下，您可以看到有关该提交的高级信息，包括历史图。

此外，您还可以看到该提交cef7440的文件差异。

2.7.2. VS2022中的Blame

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

Blame屏幕：

右键单击感兴趣的代码行：

提交cef7440的提交详细信息：

提交cef7440的历史记录图：

2.7.3 SourceTree中的Blame

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

右键单击感兴趣的代码行：

提交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. 参考资料

https://www.codeproject.com/Articles/5338960/Git-Comparing-Visual-Studio-2022-with-MeGit-EGit-a

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/凡人多烦事01/article/detail/578514