似乎git merge提交了我在一个父级上做出的修改。具体来说，一个父级包含更改（从文件中删除一些行，并删除另一个文件），另一个父级不包含这些更改。合并的结果不包含更改。合并提交中的git show显示删除的行被添加到文件中而不是删除这些行。 git show没有显示对已删除文件的任何更改。
我试图理解为什么合并结果不包含更改。合并提交消息不表示有关受影响文件的任何冲突。
我的问题是：有没有办法发现哪些标志应用于合并？ （是否有任何标志不会从包含它们的父项中引入更改？受影响的文件没有冲突，那么 - 或者 - 会对它们产生影响吗？）
我担心可能还有其他文件遭到破坏。我想我会尝试一些git diff的排列试图找到那些。关于这一点的任何建议都是受欢迎的。
答案 0 :(得分：2)
我的问题是：有没有办法发现哪些标志应用于合并？
简短的回答是否定的。合并完成后，作为结果记录的唯一内容是在提交对象本身，与任何其他提交一样，记录您的姓名和电子邮件地址和时间戳（作为作者和提交者），父提交哈希值（两者）主要输入 - 第三个输入，合并基础提交，从这些输出自动计算），您的日志消息，当然还有最终快照。
（是否有任何标志不会从包含它们的父项中引入更改？
是
受影响的文件没有冲突，所以 - 或者 - 会对它们产生影响吗？）
git merge命令本身没有--ours和--theirs;相反，它有一组令人困惑的选项：
-s ours：完全忽略其他提交;找不到合并基地;只需进行使用当前索引内容的合并提交。 （这种方式永远不会有任何冲突，因为Git甚至没有看到他们的变化。）-X ours：只要有冲突，就会使用我们的更改自动解决它们。如果对同一文件存在其他未经冲突的更改，请使用对该文件的更改。-X theirs：只要存在冲突，就会使用更改自动解决问题。与-X ours一样，这仅影响文件中的冲突区域;非冲突的变化照常合并。如果根本没有任何未解决的冲突，git merge会在合并过程中停止，并为您（执行合并的人）提供完全控制权。此时， --ours和--theirs选项，git checkout。
我担心可能还有其他文件遭到破坏。我想我会尝试一些git diff的排列试图找到那些。关于这一点的任何建议都是受欢迎的。
这是可能的;请注意，您可以运行git show -m将合并拆分为两个单独的虚拟提交，一个将父级＃1作为其单个父级（以便git diff将父级与合并结果区分开），以及一个parent＃2作为其单个父项（因此，由git diff运行的第二个git show -m将使另一个父项与合并结果区分开。）
要查看合并的输入是什么，请运行：
git merge-base --all <hash of first parent> <hash of second parent>
输出是合并基础的哈希ID。理想情况下，这里只有一个哈希ID（如果有两个或更多，请查找“虚拟合并库”）。保存该哈希ID，然后运行：
git diff --find-renames <merge base hash> <hash of first parent>
和
git diff --find-renames <merge base hash> <hash of second parent>
你会看到Git在三个输入中看到了什么。
您可以轻松完成的另一件事是重复合并。如果你给自己一个分离的HEAD，指向父＃1，然后运行git merge <hash ID of parent #2>，你将重复相同的合并（可能有不同的标志，因为我们不知道第一次使用了什么标志）。 请确保您在此之前已停用git rerere，否则Git将重新 - 使用 re 有线重新解决方案。< / strong>您现在可以手动重新解决冲突并提交。新提交将是一个新的分离HEAD，您现在可以将此提交的内容与原始合并提交的内容区分开来：
git diff HEAD <other merge commit ID>
看看你是否以不同的方式解决问题。