我注意到git merge在进行合并时似乎没有做稳定的排序。或者它可能是完全不同的东西。我真的不知道出了什么问题。
如果你试试这个小型试验箱10-20次，直到它说“FLAKY”：
mkdir a; cd a; output=$(git init .; touch 0; git add 0 ; git commit -m0; git checkout -b b1; touch 1; git add 1; git commit -m1; git branch b2 master; git checkout b2; touch 2; git add 2; git commit -m2; git checkout master; git merge b1; git merge b2 -m"merge";) test=$(git log --format=%s|xargs echo); if [[ "merge 2 1 0" == "$test" ]]; then echo "FLAKY " $test; else cd ..; rm -rf a; fi; 2> /dev/null
（它是一个oneliner，你可以在bash提示符下运行它）
通常，您在末尾回显的日志将如下所示：
merge 1 2 0
但过了一会儿，你可能会得到1和2来切换位置：
merge 2 1 0
令人难以置信的真气。我总是可以让这两个第一次提交在测试中可以互换，但我宁愿不这样做。我宁愿去除赘肉。有人知道是什么原因导致的吗？
答案 0 :(得分：0)
TLDR ：这是一种易于触发的竞争条件，因为git log按1秒的分辨率按时排序。可能的解决方法是使用：
git log --topo-order
所以在调查之后。 Git订单根据日期/时间提交。这很明显。存储的日期是自纪元，unix时间戳以来的秒数，因此分辨率非常糟糕。当所有提交具有相同的时间戳（通常情况）时，它将选择以某些（稳定！）顺序“合并1 2 0”对它们进行排序。
但是，有时候，当时间发生变化时，最后2个正好 ，因此它会有一个更高的时间戳，因此总是位于1之上。
所以这是常见的情况：
Merge: a217d34 1f853fc
Date: 1381855683 +0200
merge
commit a217d34c3b7694e4a5f963ead624b4d3e4a87adf
Date: 1381855683 +0200
1
commit 1f853fc9acf669929ccab71d341784a525a5360e
Date: 1381855683 +0200
2
commit 490507918504597c90300889aaf3cb5cbb5dd82c
Date: 1381855683 +0200
0
这是一个特殊的（片状）案例。至少在这个测试中，我想它在我的真实测试中可能会有所不同，只有当他们突然有相同的时间才会出现问题。
Merge: a2f0bba f3b9f1e
Date: 1381855747 +0200
merge
commit f3b9f1eeeef0c8c77aa8505224198951dc6d6904
Date: 1381855747 +0200
2
commit a2f0bba815bb2a1e8e611f755397350c732b5e6b
Date: 1381855746 +0200
1
commit ab28f3063df4d51c79ee0fbdec0ae77f870e8e3b
Date: 1381855746 +0200
0
我还没有设计出我要遵循的计划来解决这个问题，但似乎git log --topo-order会这样做。它至少在这个小测试中表现相同。