这种情况我在日常用Azure DevOps管理代码时也碰到过几次，主要有以下几个常见原因：

• PR合并方式选择了压缩或变基合并
  Azure DevOps的PR合并提供了多种选项，如果选了压缩合并（Squash merge），它会把PR里所有提交打包成一个全新的提交（比如你说的190abbec），这个提交直接挂在目标分支的最新节点上，不会保留原PR分支的历史链路，看起来就像是突然“空降”在历史树里，和之前的分支历史断开。
  要是选了变基合并（Rebase and fast-forward），它会把PR分支的提交逐个重放到目标分支的最新提交上，生成全新的提交对象，原PR分支的旧提交会被丢弃，自然和原来的历史失去关联。

• PR分支本身的历史就和主分支脱节
  如果你的PR分支是从一个很早的、已经被废弃的分支切出来的，或者中途有人用git push --force强制修改了该分支的历史，导致这个分支的提交链和主分支的公共历史没有交集，合并后这个190abbec提交就会显示成一个独立节点，和早期主分支历史无法关联。

• Azure DevOps界面的缓存或渲染问题
  有时候并不是Git历史真的出问题了，而是Azure DevOps的Web界面缓存了旧数据，或者渲染逻辑临时抽风。你可以试试刷新页面，或者在本地用Git命令查看真实的历史树：

  git log --graph --oneline --all
  

  如果本地显示的历史是连贯的，那大概率是界面显示的问题，清理浏览器缓存或者等一会儿就能恢复正常。

• 冲突解决操作不当导致历史断裂
  合并PR时如果遇到复杂冲突，手动解决后要是不小心直接用git commit提交，而没有正确完成合并流程，或者在冲突解决时误改了提交的父节点信息，就会导致190abbec这个新提交没有正确指向主分支的历史节点，从而在树视图里显示为孤立节点。

内容的提问来源于stack exchange，提问作者Haukland