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

Question

在处理合并时,我不能让GFS在Visual Studio中正常工作.基本上,当我拉出最后一个版本的代码时发生的每个合并操作都是一场噩梦.

我特别谈到从同一个分支中拉出某人的其他代码时发生的合并(即我不是在谈论涉及多个分支的场景).

我还特别谈到Visual Studio的内置GIT插件,所以如果IDE中有另一个解决方案,请不要建议执行我知道的命令行命令(例如rebase)("你但不能"将是一个有效的答案".

以下是重现问题的方法:

• 有两个开发人员,A和B,在同一个分支上工作
• 开发人员A推送一些修改文件F1和F2的提交
• 开发人员B修改文件F1和F3
• 开发人员B对F1和F3进行修改
• 开发人员B执行拉动:Visual Studio检测到文件F1上的冲突(这是预期的)
• 开发者B解决了F1上的冲突

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

据我所知,本地 F2文件与拉动之前不一样,但问题是B在推动之前基本上无法检查他对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 中称为任何名称）所有文件而不会发生冲突，它们将成为“合并提交”的一部分。

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

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