在 Visual Studio 中执行 GIT PULL 时如何正确处理合并

Question

在处理合并时，我无法使 GIT for TFS 在 Visual Studio 中正常工作。基本上，当我提取最后一个版本的代码时发生的每个合并操作都是一场噩梦。

我专门讨论的是从同一分支中提取其他人的代码时发生的合并（即我不是谈论涉及多个分支的场景）。

我也是特指Visual Studio的内置GIT插件，所以如果有我知道的命令行命令（比如rebase），请不要建议执行是 IDE 中的另一种解决方案（“你不能” 将是一个有效的答案）。

重现问题的方法如下：

• 有两个开发人员 A 和 B 在同一个分支上工作
• 开发者 A 推送一些修改文件 F1 和 F2 的提交
• 开发者 B 修改文件 F1 和 F3
• 开发者 B 在 F1 和 F3 上提交修改
• 开发人员 B 执行拉取操作：Visual Studio 检测到文件 F1 上的冲突（这是预期的）
• 开发者 B 解决 F1 上的冲突

现在问题来了：对于 B，所有文件 F1、F2 和 F3 都处于已修改状态。为什么？开发人员 B 只修改了文件 F1 和 F3。 我没有看到 F2 处于已修改状态的正当理由，因为 B 没有修改它。

我了解本地F2文件和pull之前不一样，但是问题是B在push之前基本上不能回顾他在F1和F3上的改动，因为都是别人的工作（在上面的简化情况下，在 F2 上）也出现在他的更改列表中。

在我们的现实世界场景中，有多个开发人员在同一个分支上工作，每次合并都是分支历史中的一次重大失败：Visual Studio 基本上显示了一堆 50 左右每次合并都修改了文件（当开发者只修改了 1 或 2 个文件时）。

此问题总是出现在最新的 Visual Studio 2013 中。Visual Studio 2015 似乎足够聪明，不显示 F2 已修改，但不是总是。

如何解决此问题？目前，GIT 是一个在 Visual Studio 中使用的 PITA。

---

编辑：

这是一个视觉示例。在左侧，VS 2013 中显示的历史记录：大量修改文件。在右侧，与 VS 2015 中显示的完全相同的历史记录（相同的存储库、相同的机器、相同的提交......等等）。显然 VS 2015 显示了一些不同且稍好一些（我只看到了我的更改）。请注意，这并不总是那样工作，有时 VS 2015 会显示我没有修改的文件，就像 VS 2013 一样。

这个问题是关于我将要推送一个合并的结果时的这种行为，但是当我简单查看一个旧合并的历史时，它完全一样，如下所示：

问题是：

• 这是一个错误吗？
• 如果没有，是否记录在案？
• 无论如何，我应该如何使用 GIT，尤其是使用 VS 2013，就如上所示的不一致问题？

Answer 1

你只需要了解 git 是如何工作的。

当你说：

开发者 B 进行拉取：Visual Studio 检测到文件 F1 上的冲突（这是预期的）

那就是你错了。 Git 检测到冲突，因此无法执行合并。 （即使你是从“相同”的分支合并，git 所做的就是创建一个合并提交来将这些分支粘在一起）。

发生这种情况时，git 会向您显示两个分支带来的所有差异。您可以 git add （或在 Visual Studio 中调用的任何内容）所有文件而不会发生冲突，它们将成为“合并提交”的一部分。

您唯一需要做的就是修复标记的冲突，让其余部分保持原样并创建合并提交。

总结，当合并失败时，您会看到变化和冲突。只需专注于解决冲突，让常规更改保持原样。

Answer 2

我已经将 Visual Studio 2013 与 Git 一起使用，它非常适合您上面提到的场景。

我可能会建议检查这些开发人员的用户设置是否存在差异。行尾、制表符空间或使用 Ctrl+K+F（格式化快捷方式）的任何更改都可能是问题。

我建议卸载除原生 VS 支持之外的任何自定义插件、工具，将 Visual Studio 更新到最新补丁。

如果问题仍然存在，请尝试在 Visual Studio 中的所有开发人员中导入相同的用户设置。参考：How to: Share Settings Between Computers or Visual Studio Versions

工具 => 导入和导出设置.. =>

下一个=>

将此设置导出并导入所有其他用户，以便所有用户都具有相同的设置。

不同的插件，如 git 扩展、tortoise git 或任何其他自定义 git 扩展都可以使用行尾或默认制表符空格，从而导致任何开发人员在几乎所有更改的文件中检测到更改。