Git Graph（mhutchie开发）最可靠：原生命令驱动，严格还原Git DAG拓扑，merge节点菱形标识、parent顺序精准；而GitLens折叠合并提交，Git History已停更。
直接装 Git Graph（作者：mhutchie）——它不依赖 Webview，渲染快、响应稳，能准确还原 Git 的 DAG 结构，不是“看起来像分支图”，而是和 git log --graph --all --simplify-by-decoration 输出严格一致。
为什么 Git Graph 比 GitLens / Git History 更可靠
GitLens 默认只显示线性历史，merge commit 常被折叠，容易误判“分支没合进去”；Git History 已停止维护，大仓库加载慢甚至崩溃。而 Git Graph 用原生命令驱动，节点位置、箭头方向、parent 顺序都和 Git 内部指针完全对齐。它不画假分支，也不省略悬空提交以外的任何拓扑关系——只是默认不显示全部分支而已。
必须手动开启 “Show All Branches” 才能看到真实分支走向
安装后默认只显示当前分支及其直系祖先，其他分支（比如已合入 main 的 feature/login）不会自动展开。你会看到一条直线，误以为“合并失败”或“提交丢了”。解决方法很简单：
- 打开
Git Graph视图（快捷键Ctrl+Shift+G或命令面板输入Git Graph: View Git Graph） - 点击右上角齿轮图标 → 勾选
Show All Branches - 点
Refresh按钮强制重载
此时所有本地分支指针都会出现在图中，带颜色的圆点 + 箭头连接，一目了然。
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
merge commit 节点是菱形，但 parent 顺序决定谁是“被合并方”
Git Graph 把第一个 parent（通常是当前分支）画在左边，第二个 parent（被合并进来的分支）画在右边。例如执行 git merge --no-ff feature/x 后，菱形节点右侧箭头指向的就是 feature/x 的最新提交。但注意：
-
git merge -s ours或 fast-forward 合并不会生成菱形节点，图里只有一条直线——这不是 bug，是 Git 本身没记录第二 parent - 右键该节点 →
View Commit Details，可确认实际parenthash 列表 - 悬空提交（
dangling commit）不会出现在图中，需单独运行git fsck --lost-found
大仓库卡顿？关 Auto Refresh + 限深拉取
超过 10k 提交的仓库，开启 Auto Refresh 会让 VSCode 主进程卡住 3–5 秒。正确做法是：
- 设置 → 关闭
Auto Refresh，改用手动Refresh - 在图形界面顶部输入框里加参数：
--all --simplify-by-decoration --date-order -n 200 - 这会跳过大量无 tag/无 branch 标记的中间
merge，只拉最近 200 条关键提交，图立刻干净，且不破坏分支拓扑
真正容易被忽略的，是那个 --simplify-by-decoration ——漏掉它，图里就缺了 HEAD、origin/main 这些关键指针，看着分支连上了，其实远程引用根本没画出来。
