在git log --decorate --oneline --graph
圣诞节前不久在我们的一个存储库中进行操作时,我们发现出现了以下结构(旋转以强调脆弱的节日主题):
提交图中的这种模式是如何产生的?
当然,这有点愚蠢,但这里有一个有趣的点——当你在 git 历史浏览器中看到提交图中的特定模式时,通常很难看到如何解释它们。
在这种情况下,情况是master
在存储库的一个克隆中的分支尖端有一个未推送的提交。然后git pull
在同一个存储库中运行了很多次,在一段时间内,上游有很多新工作正在完成。(在这种情况下,它是因为一个自动化脚本而发生的,但是如果开发人员只是反复拉入一个分支以使其保持最新,而不是说,变基,也会发生同样的事情。)
当上游有新的提交时,每次拉取都会创建一个新的合并提交,因为总是有一个提交master
不在master
上游。
最终,这个存储库中 master 分支的历史被推送到上游,所以其他开发人员在下次从上游存储库中拉取时,会在提交图中看到这个结构突然出现。
如果您有一些具有类似结构的历史记录,并且想找出是哪个提交/开发人员导致了这个问题,您可以查看带有星号的行(基本上遵循每个合并的第一个父级),直到您到达第一个非合并提交。在图片中的情况下,那是b275805
- 应该更早推送的提交。
这是人们经常喜欢使用的原因之一git pull --rebase
——它让你的未推送历史保持简单。
我的同事马修·萨默维尔(Matthew Somerville)发现了这一点,并弄清楚了发生了什么。