当某个提交（window.onload = function() {
init();
init2();
};
）有2个父提交时，如here中所述，第二个父提交是我们合并的分支上的提交，这意味着包含所引入的所有更改合并提交。这对recursive merge来说没问题。但是，如果它是recursive merge，如this，我们如何确定哪个提交引入了哪些更改？提前致谢
答案 0 :(得分：0)
更新 - 添加了一些关于基于差异的方法的说明
说第二个父级是正常合并中所有更改的来源有点误导。可能存在手动冲突解决方案，或者有人可能只与--no-commit选项合并，并在合并期间引入其他更改。考虑到合并与其父母的不同之处，考虑哪个父母引入了每个变化，这一点更为普遍适用。
但是，根据“这种变化来自何处”，可以有用。根据您真正的信息，您可以从其中一个开始：
1）git blame将告诉您每行代码的提交。源自HEAD^..branchN中的提交的任何内容都必须表明branchN上的更改。但是，由于您提供的信息是每行代码的提交ID，因此需要进行大量的后处理才能实现更改。
2）你可以为每个分支做一个差异。最初我在想
git diff HEAD^ HEAD^2
等等（用HEAD^2替换每个合并分支的引用）。这是可以的，除非主分支发生了很大变化，因为其他分支发散（在这种情况下，这些变化的反转将出现在每个差异中）。
你真正要求的是每个分支提示与分支开始分歧的点之间的差异;所以，如果你能找到“共同的祖先”，也许只需使用它：
git diff A HEAD^2
（其中A是从HEAD^和HEAD^2可以访问的最新提交。虽然这是一种直接表达（一次一个分支）的直接方式，但它确实需要在每种情况下追踪共同的祖先。 （我可能没有想到的好捷径;如果发生这种情况，我会回来更新。）
如果分支拓扑过于混乱，这可能仍然有点不清楚。例如，如果branch3实际上是从branch2分支出来的，那么您必须决定是否要将branch3与HEAD或{{branch2区分开来。 1}}（前一种方法意味着某些更改将归因于branch2和branch3）。
使用单个命令生成所有差异会很好，而表面上这是-m或log的{{1}}选项所做的事情;但这会让我们回到我的答案的开头，因为你得到与每个分支合并的差异（不是每个分支引入的变化），并且必须在心理上否定每个变化。 （即你必须寻找一个分支，其diff 不包含一个变化，以了解变化的来源）。