git log --graph 呈毛线团状，根本原因是 merge 提交天然生成分叉-汇合结构，每次 merge 都创建带两个父节点的提交，多人频繁向 main 合并时图谱退化为蜘蛛网，这是 git 忠实记录协作时序的设计使然。
为什么 git log --graph 看起来像毛线团？
根本原因不是 Git 本身出错，而是 merge 提交天然产生分叉-汇合结构。每次 git merge 都会生成一个带两个父提交的节点，分支线在图谱中必然交叉、回绕、嵌套。尤其当多人频繁向 main 合并时，图谱迅速退化为“蜘蛛网”。这不是 bug，是设计使然——Git 忠实记录了真实协作时序。
用 git log --graph + 限定参数快速看清主干
默认 git log --graph 把所有引用、所有合并都展开，信息过载。真正有用的是聚焦主线演进：
-
git log --graph --oneline --all --simplify-by-decoration：只显示带标签/分支名的提交，过滤掉中间 merge 节点 -
git log --graph --oneline main --simplify-by-decoration：仅限main分支及其直接祖先，排除 feature 分支的“毛刺” -
git log --graph --oneline --first-parent main：只追踪main的第一父级（即 merge 时的“目标分支”路径），彻底跳过被合并进来的分支历史
rebase 不等于“美化”，它改变历史且有协作风险
很多人想用 git rebase 把 feature 分支“拉直”到 main 末尾，让图谱变线性。但要注意：
- rebase 后的提交 SHA 完全不同，原提交已不可达——别人基于旧 commit 的工作会失效
- 如果 feature 分支已被推送到远程且他人已基于它开发，
git push -f会强制覆盖，破坏他人本地历史 - 丢失 merge 提交本身携带的语义：它明确记录了“某功能在此刻集成”，而 rebase 后只剩孤立提交，协作上下文消失
真正可持续的视觉净化靠工作流约束
图谱混乱本质是协作模式外显。不改流程，只调命令，治标不治本：
- 禁止直接向
main执行git merge feature/*，全部走 Pull/Merge Request，由 CI 自动创建 merge commit 并统一命名（如merge: feat/login from !123） - 要求所有 feature 分支在合并前
git rebase main（仅限未共享分支），确保其基线干净，减少三方合并复杂度 - 定期用
git branch --merged main | grep -v "main\|develop" | xargs git branch -d清理已合入的旧分支，避免图谱被冗余指针拖累
图谱是否“干净”，最终取决于团队对分支生命周期和合并语义的共识，而不是某个命令能否让它看起来顺眼。
