git log --graph 连线歪斜或断开主因是按时间顺序渲染而非逻辑对齐，同一行多分支并行提交导致斜线空格，长时间无提交造成断层，需加--all、用--topo-order、确保终端宽度足够。
git log --graph 看分支拓扑时为什么连线歪斜或断开
因为 git log --graph 是按提交时间顺序逐行渲染的，不是按分支逻辑“画图”，它只保证父子关系正确，不强制对齐。同一行里多个分支并行提交，就会出现斜线或空格分隔；如果某分支长时间没提交，后续再提交，中间就可能出现“断层”。
常见错误现象：git log --graph --oneline --all 输出中，feature/login 的提交突然跳到左边，和 main 不连贯——这不是 bug，是时间戳靠后但父提交靠前导致的渲染结果。
- 必须加
--all，否则只显示当前分支，看不到依赖起点 - 避免用
--date-order（默认），它会打乱拓扑顺序；想看真实分支结构，用--topo-order - 终端宽度不足时，
--graph会自动折行，造成视觉错乱；可临时增大 terminal width 或加--no-merges简化
用 git merge-base 找两个分支最近共同祖先
分支依赖关系的本质，就是它们从哪个 commit 分叉出去的。git merge-base A B 直接返回这个 commit hash，比肉眼数图靠谱得多。
使用场景：合入前确认 feature/search 是基于最新 develop 开发的，而不是老版本——运行 git merge-base feature/search develop，再 git show --oneline 看那个 commit 是否包含你预期的接口变更。
- 如果返回空，说明两分支完全无交集（比如一个是从远程新建拉的，另一个本地从未 fetch）
-
git merge-base --is-ancestor A B返回 0 表示 A 是 B 的祖先，适合写 CI 脚本做准入检查 - 注意：
merge-base不考虑 merge commit 的 first-parent，只找最深公共祖先，对 rebase 过的分支也有效
draw-git-branch.sh 这类脚本生成的 SVG 图为什么和 gitk 不一致
因为 gitk 和命令行 log --graph 都是实时解析对象数据库，而多数绘图脚本（如基于 git rev-list --all --simplify-by-decoration 的）会过滤掉“无标签/无分支指向”的提交，把中间 commit 合并折叠，导致分支线看起来更干净，但丢失了真实提交链。
性能影响明显：一个含 5000+ 提交的仓库，git log --graph --all 可能卡顿 2–3 秒；而 Python 脚本调用 git rev-parse + Graphviz 渲染，首次生成要 8 秒以上，但输出 SVG 可缩放、可搜索。
- 别信脚本默认的 “--simplify-by-decoration”，它会让
hotfix/1.2.3看起来直接连到main，实际中间可能隔了 12 个未打 tag 的提交 - 真要画精确图，用
git log --all --format="%H %P %D" --no-walk导出原始关系，再喂给 dot 工具 - VSCode 的 GitLens 插件底层也是走类似路径，但它缓存了 commit 关系，所以打开快——但首次加载仍需几秒解析
HEAD 指针移动和分支依赖的隐含约束
分支本身只是个轻量指针，但 HEAD 的位置决定了你 git commit 会往哪条链上追加节点。很多人以为切换分支只是改个名字，其实是在重置工作区 + 暂存区 + HEAD 三者状态。
容易踩的坑：git checkout feature/x 后立刻 git merge main，结果发现 feature/x 里多了不该有的改动——因为 main 当前 HEAD 指向的 commit，其父提交里可能包含你本地未 push 的私有提交（比如你之前在 main 上偷偷改过 config.js 测试环境变量）。
- 执行 merge 前先
git fetch origin，确保origin/main是远程最新，而不是你本地陈旧的main -
git status显示 “Your branch is ahead of 'origin/main' by 3 commits” 时，origin/main才是真实依赖基线，不是本地main - rebase 时若没加
--fork-point，Git 默认用 reflog 找上游分支上次合并点，但 reflog 本地才有，协作中这个点可能根本不存在于别人机器上
git merge 或 git rebase 时动态协商的结果。最常被忽略的，是「谁的 HEAD 当前代表权威上游」——它不在图里，但在 .git/refs/remotes/origin/ 文件里藏着。 
