为什么我的git历史看起来像一棵圣诞树？
当git log --decorate --oneline --graph我们在圣诞节前不久在我们的一个存储库中进行操作时,我们发现出现了以下结构(旋转以强调脆弱的节日主题):
提交图中的这种模式是如何产生的？
当然,这有点愚蠢,但这里有一个有趣的观点 - 当你在git history浏览器中看到它们时,通常很难看到如何解释提交图中的特定模式.
Mar*_*air 36
在这种情况下,情况是master在存储库的一个克隆中的分支的尖端处存在未刷新的提交.然后git pull在同一个存储库中运行了很多次,在一段时间内上游完成了大量新工作.(在这种情况下,它发生的原因是一个自动脚本,但如果开发人员只是反复进入分支以使其保持最新状态,而不是比较,那么同样的事情就会发生.)
当上游有新提交时,每次拉动都会创建一个新的合并提交,因为总有一个提交master不在master上游.
最终,来自此存储库中主分支的历史记录被推送到上游,因此其他开发人员在下次从上游存储库中提取时突然出现提交图中的此结构.
如果你有一些历史具有相似的结构,要找出其呈交/开发商这是造成这个问题,你可以看不起的星星(基本上遵循每一个合并的第一父级)的线,直到你到达第一次非合并提交.在图片的情况下,那是b275805- 应该提前推送的提交.
这是人们经常喜欢使用的一个原因git pull --rebase- 它可以简化您的未经处理的历史记录.
为了给予应有的信用,我的同事马修·萨默维尔(Matthew Somerville)发现了这一点,并找出了正在发生的事情.
- 优秀.+1.我只知道'pull --rebase`的潜在问题(http://stackoverflow.com/questions/2590260/when-will-git-pull-rebase-get-me-in-to-trouble/2590276 #2590276),但在这里,这将真的有帮助. (4认同)