如何检测文件是否应该在git中合并答案

【问题标题】：How to detect if a file should've been merged in git如何检测文件是否应该在git中合并
【发布时间】：2017-04-11 09:36:08
【问题描述】：

在我们团队的 git 上执行了给定的合并提交，删除了一个文件，我们只能在 tortoisegit 日志中看到：

git 命令行的日志不会产生删除（ git log --stat 的输出）：

试图找出导致删除的实际提交在 git gui 上没有结果：

此日志显示没有文件删除。

所以问题是这样的：我们如何使用 git 命令行和 TortoiseGit 来完全追踪这个“删除”并证明是什么提交（合并与否）删除了文件？

非常感谢。

编辑：使用 torek 的反馈，使用 git log -c --stat 和 git log --cc --stat 仍然没有显示哪个提交确实“删除”了文件，但它确实显示了有关合并提交的更多信息：

我已经在日志中搜索了受影响的文件，并且只获得了其他提交的添加和更改，但是使用 git log -m --numstat 我确实得到了这个：

显然，该文件的行存在于父提交 07a2fb4 中，但不存在于父提交 d0941f2 中。

如何判断合并提交中特定文件的提交“胜出”，以便检测这些丢失的文件？

【问题讨论】：

你没有显示你运行的命令行 git log 命令（精确的选项，包括任何路径名限制器，很重要）但默认情况下 git log 不显示任何关于合并提交的信息。添加-c 或--cc（注意cc 两个破折号，c 一个破折号）以获得组合差异，或-m 获得per-parent diffs（似乎 TortoiseGit 正在这样做）。如果使用路径选择器，请注意这会打开历史简化。
您好，感谢您的反馈。使用 -c 和 --cc 我确实获得了更多信息，但只是对应该在 git repo 中的文件进行了添加和修改，实际上它不是，这引起了很多混乱。我也会根据您的反馈更新问题。
组合的差异故意抑制在“正常”合并中通常是多余的信息。如果合并完成错误，这可能会隐藏一些细节。使用-m 将合并拆分为每个父操作，将合并结果单独与每个父提交进行比较；该信息与您在任何差异中获得的信息一样完整，但是笨重且难以解释。另见stackoverflow.com/q/43138569/1256452
谢谢，我一定会调查的。所以检测将是一个手动程序，对吗？您必须知道必须存在哪些文件才能确定合并是否做得不好。
差不多，是的。不过有一种更快的方法，如果您有某种可以识别“好树”与“坏树”的自动化测试：使用git bisect。设置这一切需要一些工作——尤其是编写测试（“文件不存在”可能还不够，因为可能有一些提交不应该拥有它）——但在那之后，如果你test 是可靠的，Git 会自动找到出错的提交。

标签： git merge tortoisegit

【解决方案1】：

TortoiseGit 日志对话框显示合并时双方父母的差异（因此可能包括发生在父母和合并提交之间某处的更改）。所以：

该文件已在第一个父级的历史记录中删除。
该文件已从第二个父项的历史记录中删除。
文件在合并过程中被删除。

在你报告的追逐中，我想只有案例 1 是可能的。

为了查看它在哪个提交中被删除，请选择文件并选择“显示日志”，您将看到另一个日志对话框，您可以在其中查看此特定文件的历史记录（确保“显示整个项目”不是在左下角选择）。最后一次提交应指示此文件被删除的位置。 - 为了区分最后一种情况，你还可以选择父母的每一个最后一次提交，打开存储库浏览器，看看文件是否还在。

回答你最后一个问题：没有“胜利”。 Git不关心文件是否存在于您合并的分支中，我只是重新应用更改自待合并分支的fork（或最后一次合并）以来的更改（如果文件被删除）当前分支和要合并的分支上的修改会发生冲突，如果没有触及，Git 不关心这个文件）。

【讨论】：

感谢您的信息。有趣的是，我试图从“删除”它的合并提交中获取文件日志，但我得到一个空日志......
您是如何尝试获取日志的？这里的方式可能很重要。
我按照你说的做了，我右键单击该文件并确保没有选择“显示整个项目”。它仅在勾选“所有分支”选项时显示提交。
这很好奇。尝试在日志对话框的过滤器中输入文件？