在做git log --decorate --oneline --graph
圣诞节前夕在我们的资料库之一,我们发现以下结构已经出现了(旋转强调脆弱的节日主题):
提交图中的这种模式是如何产生的?
当然,这故意有些愚蠢,但是这里有个有趣的地方-当您在git历史浏览器中看到特定模式时,通常很难看到如何解释特定模式。
Answers:
在这种情况下,情况是master
在存储库的一个克隆中,分支的末尾有未推送的提交。然后git pull
在同一存储库中运行了很多次,一段时间后,上游有许多新工作要做。(在这种情况下,发生这种情况是因为脚本是自动执行的,但是如果开发人员只是反复将其拉入分支以使其保持最新状态,而不是重新定级,则可能会发生同样的事情。)
上游有新提交时,每次拉动都会创建一个新的合并提交,因为总有一个提交master
不在master
上游。
最终,来自该存储库中master分支的历史记录被推送到上游,因此其他开发人员看到,当他们下次从上游存储库中提取时,提交图中的这种结构突然出现。
如果您有一些结构类似的历史记录,并且想找出是哪个提交/开发人员导致了此问题,则可以只看星星的行(基本上在每次合并的第一个父项之后),直到找到第一次非合并提交。在图片的情况下,那就是b275805
-应该早点推送的提交。
这是人们经常喜欢使用的原因之一git pull --rebase
-它使您未推送的历史记录变得简单。
为了给您应得的荣誉,我的同事Matthew Somerville发现了这一点,并弄清楚了发生了什么。
pull --rebase
(stackoverflow.com/questions/2590260/…)的潜在问题,但是在这里,这确实有帮助。