圆点是commit存档点，非代码改动量；彩色线是分支生命周期，非代码流向；交汇点需含双父提交才是真合并，fast-forward或squash合并不产生交汇图标。
圆点就是 commit，不是“一次改动”而是“一个存档点”
每个圆点对应 git commit 生成的一个完整快照，包含当时工作区所有文件的精确状态。它不表示“改了几个文件”或“改得多不多”，只表示“这里存了一份”。哪怕你只改了一个空格、甚至用 git commit --allow-empty 提交了个空提交，也会生成一个圆点。
常见误解是把圆点当成“一次代码变更”，结果看到密集节点就以为“这段代码很乱”。其实只是提交频率高——可能是 CI 自动提交、pre-commit 钩子频繁触发，或者团队习惯小步快跑式提交。
右键点击圆点可查看：commit hash、作者、时间、完整消息；但注意：文件列表只显示该次提交涉及的路径，不自动展开 diff —— 想看具体改了哪行，得手动右键 → Compare with Previous Commit 或打开文件后按 Ctrl+Shift+P → “Git: Open Changes”。
彩色线条是分支生命周期，不是“代码流向”
每条线代表一个分支从创建到（可能）删除的完整轨迹。线的颜色由 Git Graph 自动分配，不固定对应某个分支名；但同一分支在图中始终是同色，且分支标签（如 main、origin/feature/login）会贴在对应线的末端圆点旁。
关键区别：
-
main线不一定是“主干”——如果你当前在dev分支上工作，dev线会被加粗高亮，HEAD标签也贴在它的最新节点上 -
origin/xxx红色标签属于远程分支，它和本地xxx绿色标签之间的节点差，就是你还没git push或还没git pull的提交数 - 线与线之间没有“上下级”关系——两条线交汇 ≠ A 合并进 B，而要看交汇点的提交类型：如果是
merge commit（带 ∨ 图标或双入向箭头），才是真合并；如果是一条线直接“覆盖”另一条（无分叉、无合并图标），大概率是rebase或fast-forward
合并点长什么样？怎么确认是不是真 merge
真正的合并提交在 Git Graph 中表现为一个圆点有**两个或以上父提交**，图上显示为两条（或更多）线汇入同一个节点，且该节点通常带 ∨ 形图标或加粗边框。右键点开它，能看到 Merge: feature/login into main 这类消息。
但要注意这些陷阱：
- 用了
git merge --squash：它会把多个提交压缩成一个普通提交，不产生 merge commit，图上就看不到交汇，只有一条线平滑延伸——这不是插件没画对，是 Git 本身就没记录“这是合并” - fast-forward 合并：当目标分支没新提交时，
git merge会直接移动指针，不产生新 commit，图上就是一条线“吞掉”另一条，看似没交汇，其实是合并成功了 - rebase 后的线：如果你在
feature上git rebase main，原feature线会被切断，新提交会挂在main后续位置，看起来像“贴上去”，但这不是合并，是重放
为什么我的图一团乱？三个最有效过滤动作
默认视图会把所有分支、已删分支残留、detached HEAD、孤立提交全摊开，线条交叉不是 bug，是数据真实。想聚焦关键路径，优先做这三件事：
- 右键任意提交 →
Focus on Branch，输入你想盯的分支名（如main），视图立刻收缩为该分支及其直系祖先/后代，其他线全部隐藏 - 点击右上角 ⋯ →
Filter Commits→ 勾选Only show commits that are referenced by at least one branch or tag，瞬间剔除所有“孤儿提交”和已删分支的残影 - 关闭
Show Remote Branches（左下角齿轮设置里），除非你正处理推送/拉取冲突——远程分支线（origin/xxx）一多，图立刻变蜘蛛网
真正难的不是看懂图，而是意识到：Git Graph 显示的是 Git 对象图的忠实投影，它不猜测、不补全、不美化。你看到的混乱，往往是你仓库里真实存在的分支管理习惯——比如长期不删 feature 分支、频繁 force-push、或多人共用一个开发分支。图不会说谎，但需要你带着 Git 模型去读它。
