企业官网建设流程全解析

第一次看到git log --graph --all打出来那张斜线交错的分支图，我的第一反应是这不就是一张地铁线路图么：主干一路向前，几条支线从某个站岔出去，走一段又并回来。当时我以为 Git 分支是在磁盘上把整个项目复制了一份，所以每次git switch都要等半天。后来翻了下.git目录才发现，一个新分支在磁盘上不过是一个四十来字节的文本文件，里面就写了一串哈希值。这个认知一旦建立，后面关于合并、变基、远端分支的一堆困惑几乎是连锁解开的。

Git 分支的原理与使用，说到底就两件事：一是明白分支只是指向某次提交的可移动指针，二是明白指针怎么移动才不把别人的工作搞乱。前者属于原理，后者属于纪律。市面上讲命令的文章很多，讲清楚"这条命令在.git里改了什么"的并不多，而恰恰是后者能让你在出问题时知道往哪儿看。下面这些内容，我会按"磁盘上发生了什么 → 命令做了什么 → 出问题怎么查"的顺序展开，适合已经会用commit、push，但一遇到冲突、分离头指针、误删分支就发怵的读者。

1. 分支不是"复制一份代码"，而是一个四十字节的文本文件

1.1 从一次提交说起：commit、tree、parent 构成的有向无环图

要理解分支，得先理解 Git 存的是什么。每次git commit，Git 会生成一个 commit 对象，这个对象里包含四样东西：一个指向目录树快照的tree对象、零个或多个parent（父提交）、作者与提交者的信息、以及提交说明。注意这里没有"文件差异"，commit 指向的是整棵目录树的快照，差异是查看时才临时算出来的。

parent这个字段是整个分支模型的基石。普通提交有一个 parent，合并提交有两个甚至更多 parent。把这些 commit 用 parent 连起来，就得到一张有向无环图（DAG）——方向永远是从新指向旧，且不可能绕回自己。所谓"分支"，在这张图上就是一条从某个节点延伸出去的路径。图是只增不改的：commit 一旦生成，哈希就固定了，内容也固定了。你后面所有的"改写历史"操作，本质上都是生成新的 commit 对象，然后让指针指过去，旧对象还在，只是没人引用了。

我习惯用一个类比：commit 像是一张张已经冲洗好的照片，哈希就是照片的编号；parent是照片背面写的"上一张的编号"。照片本身不能修改，你只能重新拍一张，然后把相册目录里的页码改掉。这个类比在后面讲 rebase 为什么会导致哈希全变时，会非常有用。

1.2 refs/heads 与 HEAD：分支名只是指针的别名

.git/refs/heads/目录下，每一个文件就是一个本地分支，文件名就是分支名，文件内容是它当前指向的 commit 哈希。你可以直接cat .git/refs/heads/main看一眼，输出就是一行四十位（SHA-1）或六十四位（SHA-256）的十六进制字符串。这就是全部——没有代码副本，没有目录拷贝。

那 HEAD 是什么？.git/HEAD通常只有一行：ref: refs/heads/main。它是一个"符号引用"，意思是"我现在站在 main 这个分支上"。所以一次提交发生时，Git 做的事情极其简单：生成新 commit，把refs/heads/main这个文件的内容改写成新 commit 的哈希。指针往前挪一格，完事。

这里有个细节很多人没注意：分支文件是可以被外部工具直接读写的。我曾经在排查一个自动化脚本的问题时发现，脚本为了"批量创建分支"，直接往refs/heads/里写文件，结果因为没走git update-ref，跳过了 reflog 记录，后来误删时连恢复线索都没有。所以哪怕是原理层面的操作，也建议用git update-ref这类正式入口，别手工写文件。

1.3 为什么切分支几乎瞬间完成

理解了上面两点，切分支为什么快就很好解释了。git switch other做的事情是：把.git/HEAD的内容改成ref: refs/heads/other，然后更新工作区和索引，使之与目标 commit 的 tree 一致。指针切换本身是 O(1) 的，代价全在第二步的文件同步上——而 Git 只同步两边真正不同的文件，靠的是索引里记录的 stat 信息（修改时间、大小、inode）做快速比对。

所以你会观察到一个现象：在一个几万文件的大仓库里，如果两个分支只差三个文件，切分支几乎是眨眼的事；但如果两个分支差了上万个文件（比如一个分支删了整个 vendor 目录），那切换就会明显变慢，因为工作区要真正重写这些文件。这个规律在实操中很有用：分支切得慢，往往说明你的分支划分方式有问题，两个分支承担了过多不相关的变更。

还有一个反直觉的点：分支数量多几乎不影响性能。因为每个分支就是一个几十字节的文件，一百个分支也就几 KB。真正影响性能的是分支之间的差异大小和仓库对象数量。所以别怕建分支，该建就建。

2. 切分支时 Git 到底改了哪些文件

2.1 .git 目录里那三个关键位置

出问题时想快速定位，必须记住三个位置。第一个是.git/HEAD，它告诉你当前在哪儿；第二个是.git/refs/heads/，它告诉你所有本地分支指向哪儿；第三个是.git/logs/，也就是 reflog，它记录了 HEAD 和各个 ref 的每一次移动，格式是"旧哈希 新哈希 操作者 时间 动作描述"。

reflog 的重要性怎么强调都不过分。它是一份"本地操作流水账"，默认保留 90 天（可通过gc.reflogExpire配置调整）。误删分支、误 reset、误 rebase 之后，绝大多数救援都从git reflog开始。我个人的习惯是，在做任何"破坏性"操作（reset --hard、rebase、branch -D）之前，先顺手git reflog | head -5看一眼当前状态，心里有个锚点。

另外还有一个容易被忽略的文件：.git/index。它是暂存区，记录的是"下一次提交要包含哪些文件、各自对应哪个 blob 哈希、以及文件的 stat 信息"。切换分支时，index 必须和目标分支的 tree 保持一致，否则你git status会看到一堆莫名其妙的"已修改"。这就是为什么有时候切完分支，编辑器里文件没变，但git status说改了一大片——多半是行尾或文件权限导致的 stat 失配。

2.2 工作区与索引的同步：checkout 的真实动作序列

git switch（或老版本的git checkout）内部大致走这么几步：先做一遍安全检查，确认当前未提交的改动不会和要切换的目标分支冲突；然后把 HEAD 指向目标分支；接着对比当前索引和目标 tree，算出需要增删改的文件列表；再更新工作区文件；最后更新索引。这个顺序解释了为什么如果有未提交改动且目标分支也改了同一批文件，切换会被拒绝——安全检查没过。

被拒绝时的报错通常是Your local changes to the following files would be overwritten by checkout。这时候千万别条件反射地git checkout -f强切，那会直接丢掉你的改动。正确做法是先git stash，切过去，再git stash pop；或者对这批改动单独建一个临时提交。

还有一个隐蔽的坑：新创建但未被跟踪的文件不会阻止切换。因为 Git 只保护"已跟踪文件"的改动。所以如果你在分支 A 上新建了一个config.local.js还没add，切到分支 B 时它会被带过去——如果分支 B 恰好也有一份同名但已跟踪的文件，你会看到内容莫名其妙变了。这类问题排查起来极费时间，我一般建议在项目里配好.gitignore，把本地配置文件全部列进去。

2.3 未提交改动会被带走，这是很多事故的源头

承接上一条，未跟踪文件会被"带"到目标分支，这是 Git 的既定行为，不是 bug。理解这一点之后，很多"诡异现象"就说得通了：明明没提交，切个分支怎么代码就不一样了？因为那个文件在两个分支里都存在且已跟踪，切换时被覆盖了。

我踩过最典型的一次：在一个特性分支上改了一个公共工具文件，改到一半没提交就去切主干查问题，回来后发现改动没了。当时第一反应是"Git 吞代码了"，冷静下来git reflog一看，切分支那一步并没有丢失任何提交——问题在于那次改动是已跟踪文件的修改，切换时被目标分支的版本覆盖，而我没有提交也没有 stash。后来我的习惯是：切分支前必看git status，如果有已跟踪文件的改动，要么提交，要么 stash，绝不裸奔切换。

顺便说一个提升效率的配置：git config --global merge.conflictStyle zdiff3（新版本支持）。它会在冲突标记里额外展示共同祖先版本，解决冲突时能直接看出"两边各自改了什么"，比默认的两栏标记信息量大得多，尤其在三方合并冲突复杂的时候。

3. 合并的三种结局：快进、三方合并、冲突

3.1 快进合并：条件与副作用

当目标分支是当前分支的直接祖先时，合并可以快进（fast-forward）：既然没有任何分叉，那就把当前分支的指针直接挪到目标分支的哈希上，不生成新 commit。命令输出里那句Fast-forward就是它。

快进的好处是历史干净、线性、没有多余的合并节点。但副作用也很明显：合并这个动作在历史上不留痕迹。事后你从图上看，会觉得这些提交本来就是直接在主干上开发的，根本看不出曾经有过一个特性分支。这在需要追溯"哪个需求对应哪批提交"的场景下是个损失。

所以有些团队会在合并特性分支时强制--no-ff，即使能快进也生成一个合并提交，让分支边界留痕。这是一个纯粹的取舍问题，没有对错：

我自己在个人项目里用默认快进，因为提交粒度控制得比较细；在多人协作的项目里倾向--no-ff，因为需要"一个合并节点对应一个需求"这个可追溯性。

3.2 三方合并：merge base 决定了什么算"改动"

有分叉时，Git 会走三方合并（three-way merge）。关键在于找到merge base，也就是两个分支的最近共同祖先。找到之后，Git 做的是三方对比：base → 当前分支得到"我方改了什么"，base → 目标分支得到"对方改了什么"，然后按文件、按块（hunk）把两边不冲突的改动都应用上去。

注意：三方合并对比的是"相对于共同祖先的变更"，不是"两个分支的当前内容"。这解释了一个常见困惑——为什么两个分支的文件内容看起来完全一样，合并时却报冲突？因为它们相对于 base 都做了改动，而且改在了同一区域，Git 无法判断该保留哪个。

git merge-base A B可以显式查看共同祖先，排查合并问题时非常有用。另外git log --merge -p <file>能列出冲突文件在两边各自的提交，配合git diff --name-only --diff-filter=U找出所有冲突文件，这套组合拳在处理大合并时能省不少时间。

合并提交与普通提交的区别就在于它有两个 parent。这一点在后续做git log --first-parent时特别有价值——只看第一父链，就能把主干历史过滤成一条干净的线，跳过所有分支内部的细碎提交。

3.3 冲突标记的读法与解决套路

冲突时文件里会出现这样的标记：

<<<<<<< HEAD 当前分支的版本 ======= 要合并进来的分支的版本 >>>>>>> feature/login

上半部分是你所在分支（HEAD）的内容，下半部分是对方分支的内容。解决方式无非三种：保留我方、保留对方、手工融合。改完之后必须git add <file>标记为已解决，然后git commit完成合并提交。

我见过不少人改完文件就直接git commit -a，看似没问题，但-a会把所有已跟踪文件的改动一股脑提交，包括那些你根本没检查过的冲突文件。规范做法是先git add逐个确认，再git commit。

再分享一个提效技巧：git config --global merge.conflictstyle diff3之后，冲突标记会多出一段|||||||分隔的共同祖先内容。对于"两边都改了一大段、看不出意图"的冲突，祖先版本能直接告诉你原本长什么样，判断该保留哪边会快得多。我自己用了这个配置之后，解决冲突的时间大概缩短了一半。

git mergetool也是一个选项，但如果团队没有统一的图形工具约定，反而容易产生格式差异。我的建议是：简单冲突手改，复杂冲突用git checkout --ours <file>/--theirs <file>先整体取一边，再局部手动调。注意在 rebase 过程中，ours和theirs的含义是反的——ours指的是你正在 rebase 到的那个基底分支，这点坑过很多人。

4. rebase 的本质是把提交"重放"一遍

4.1 一次 rebase 内部发生了什么：哈希为什么全变了

git rebase main在特性分支上执行时，Git 做的是：找到特性分支与 main 的共同祖先，把共同祖先之后特性分支上的提交逐个取出来，以 main 的最新提交为新的基底，依次重新应用，每应用一次就生成一个新的 commit 对象。因为 parent 变了，commit 内容也变了（哈希由内容算出），所以所有被重放的提交哈希都会变。

这就是为什么 rebase 之后git log看起来"历史被改写了"。严格说不是改写，是新建了一批提交，旧的那批还在对象库里（直到被 gc 回收），只是分支指针指向了新的那批。这也解释了为什么 rebase 之后你本地原有的、基于旧提交的其他分支会"分叉"出去——它们还指向旧的哈希。

理解这层之后，rebase 的一大堆"规矩"就都顺理成章了：凡是别人已经基于旧哈希做了工作的地方，你 rebase 就会让别人对不上号。所以那条红线——不要对已经推送并被他人使用的公共分支做 rebase——不是一个道德规范，而是一个技术后果。

4.2 交互式 rebase：整理提交的四种常用动作

git rebase -i HEAD~5会打开一个编辑器，列出最近五个提交，每行前面是一个动作关键字。最常用的四个：

• pick：保留这个提交，什么都不改
• reword：保留改动，重新编辑提交说明
• squash：把这个提交合并进上一个提交，两条说明都保留供编辑
• fixup：同 squash，但丢弃本条的说明，直接用上一条的

还有drop（删掉这个提交）、edit（停下来让你修改内容）、以及调整行顺序来重排提交顺序。我在提交前整理时最常用的是fixup：开发过程中随手提交一堆wip、fix typo，最后用git rebase -i把它们压进对应的功能提交里，形成一组逻辑清晰的提交再推上去。

这里有个实操细节：git rebase -i的列表顺序是从旧到新，和git log展示的顺序相反。第一次用的人经常会挑错提交。我的做法是先用git log --oneline -10看清楚，再执行交互式 rebase，心里有数。

另一个细节：squash时编辑器的内容是几条提交说明拼在一起，建议保留一条主说明，把其余内容降级成正文条目，而不是简单堆叠。这属于提交习惯问题，但会直接影响后来人 review 的成本。

4.3 那条被反复强调的红线：公共分支不要 rebase

判断标准很简单：这个分支上有没有别人的提交，或者别人有没有基于它继续工作。如果是，就别 rebase。如果只有你自己，且确定没有别人基于它建分支，那 rebase 是安全的，甚至是推荐的。

真正麻烦的场景是"我已经 rebase 并强推了，怎么补救"。这里没有优雅方案，只能靠沟通加git reflog。同事的本地分支还指向旧提交，需要他们执行git fetch后git reset --hard origin/<branch>（前提是他们本地没有未推送的提交），或者用git rebase --onto精确地把自己的提交搬到新历史上。无论哪种，都会有人要做手工操作，所以代价是实实在在的。

提示：如果团队里确实需要用 rebase 来保持历史线性，一个更稳妥的做法是"只在本地分支上 rebase，推之前做一次 squash 整理，推上去的提交视为不可变"。这个约定比单纯说"别 rebase"更容易执行。

还有一个常被忽略的点：rebase 过程中每一个提交都可能产生冲突，而且冲突可能要解决很多次（每个被重放的提交各来一遍）。如果分支上提交很碎、冲突文件又相同，用git rerere（记录并复用冲突解决方案）能省大量重复劳动。开启方式是git config --global rerere.enabled true，之后同样的冲突会被自动解决，你只需要git add确认。

5. 远端分支是一份只读快照，不是"别人电脑上的分支"

5.1 fetch、remote-tracking branch 与本地分支的三层关系

很多人的困惑来自把origin/main和main当成了同一个东西。实际上这是三层完全不同的东西：

1. 远端仓库里的main，真实存在于服务器
2. 本地的origin/main，是远端状态在你本地的只读快照，只有fetch/pull时才会更新
3. 本地的main，是你自己的工作分支，只有你自己能移动它

git fetch只更新第 2 层，不动第 3 层，也不动工作区。所以 fetch 之后git status可能会告诉你"你的分支落后于 origin/main 3 个提交"，但你的代码一行没变。这是一个非常安全的信息同步动作，我每天的例行操作就是git fetch --all --prune，先看清楚全貌再决定做什么。

git pull等于fetch+merge（或fetch+rebase，取决于配置）。默认的 merge 行为会产生合并提交，如果本地有未推送的提交，历史会变得很杂。我个人习惯配置git config --global pull.ff only，让 pull 在有分叉时直接失败，逼自己显式选择 merge 还是 rebase。这个配置看着麻烦，但能避免很多"莫名其妙多出一个合并提交"的情况。

5.2 upstream 的设置与它在 push/pull 时的作用

本地分支可以通过upstream（也叫 tracking）关联到一个远端分支。设置之后，git push、git pull、git status都能省略远端和分支名，直接知道该跟谁交互。设置方式有两种：

# 首次推送时直接建立关联 git push -u origin feature/login # 对已有分支补充设置 git branch --set-upstream-to=origin/main main

查看关联状态用git branch -vv，输出会列出每个分支的 upstream 以及"领先/落后"的提交数。这个命令我几乎每天都会敲，它给的是全局视图——哪个分支该推、哪个该拉，一眼就清楚。

一个小坑：upstream的配置写在.git/config里，是本地文件，不会被提交。所以新建的本地分支如果不-u推一次，别人是看不到这个关联的，而你自己换台机器也要重新设。这不影响仓库本身，但会影响"这个分支该往哪儿推"的默认行为。

5.3 远端分支残留：为什么列表里总有一堆 delete 不掉的

git branch -r看到一堆已经删掉的远端分支，这是常见现象。原因是远端的删除动作只会在你 fetch 时同步，而默认的fetch不会自动清理已删除的远端跟踪引用。解决办法是加--prune：

# 一次性清理 git fetch --prune # 或者配置成默认行为 git config --global fetch.prune true

我强烈建议把fetch.prune设为全局默认。不加这个配置，origin/feature/old-xxx会一直挂在那儿，时间长了分支列表能翻三屏，而且容易误以为那些分支还在。

还有一种残留更隐蔽：远端分支确实还在，但你推送时提示remote: error: cannot lock ref。这多半是因为本地存在一个名字相似但大小写不同的引用（比如Feature/Login和feature/login），在某些文件系统上会冲突。排查办法是git for-each-ref列出所有引用对比大小写，这种情况只能删掉一个再重建。

6. 实战：一套能长期维护的分支约定与日常动作清单

6.1 命名与生命周期：主干、集成分支、特性分支

分支模型不用搞得太复杂，我实践下来最能长期维持的是两层半结构：一条长期主干（main），若干短生命周期的特性分支（feature/xxx、fix/xxx），必要时加一条预发布分支（release/x.y）。特性分支的生命周期应该以"天"为单位，超过一周的分支一定会开始积累大量冲突。

命名上我坚持两个原则：带类型前缀（feature/fix/refactor/docs）和短横线分词，不用中文、不用空格、不用大写。前缀的价值在git branch列表里体现得最明显——一眼就能区分哪些是待合并的功能、哪些是临时救火。我见过用"人名+日期"命名的团队，分支列表里全是zhangsan-0815，完全看不出内容，最后没人敢删。

分支的死亡时间也要有约定：合并后立刻删。本地删git branch -d xxx，远端删git push origin --delete xxx。-d是安全删除，会检查是否已合并；确认要强删时用-D。养成"合并即删"的习惯，分支列表才能一直保持可读。

6.2 每天都要敲的那几条命令

工具的价值在于形成肌肉记忆。我把日常动作压缩成一张速查表，贴在编辑器旁边：

其中"从origin/main起手"这一条，是减少后续冲突成本最有效的做法。很多人习惯从本地main拉分支，而本地main可能已经落后几十个提交，等到要合并时才发现一堆冲突。改成从origin/main起手，再配合每天fetch，冲突量会明显下降。

还有git stash push -m，一定要带说明。不带说明的 stash 列表里全是WIP on main: 3f2a1b ...，过两天根本认不出哪个是哪个。带说明的 stash 至少能靠git stash list找到线索。

6.3 stash、cherry-pick、worktree 三个救场工具

stash解决"手上有活但必须切分支"的问题，前面提过了。补充一个细节：git stash pop会删除 stash 记录，如果 pop 时冲突了，记录会保留，你先解决冲突再git stash drop；而git stash apply则始终保留记录。我一般用apply，确认没问题后再手动drop，多一步但更保险。

cherry-pick解决"只想拿某一个提交"的问题。比如你在特性分支上顺手修了一个主干也需要的小 bug，可以直接git cherry-pick <sha>把它摘到主干，不必合整个分支。注意它同样是生成新提交、哈希会变，所以不能指望靠哈希在两个分支间做对应关系。如果摘的是合并提交，需要-m 1指定看哪个 parent，这个参数不熟悉的话容易摘出诡异结果。

worktree是这三个里最少人用、但最能提升效率的。git worktree add ../hotfix hotfix/urgent可以在另一个目录里检出另一个分支，两个目录共享同一个.git对象库，但工作区互不干扰。它的价值在于：你不用再为了救火而 stash。主线继续开发，另一个窗口处理紧急问题，互不影响。我在需要同时对照两个分支的代码、或者跑长时间构建时，几乎都会开一个 worktree。

7. 出事之后的补救：几个高频故障的完整排查链路

7.1 误删分支：从 reflog 里把提交捞回来

链路是这样的：先git reflog找到被删分支最后一次指向的提交哈希，再git branch <name> <sha>重建。因为 reflog 记录的是 HEAD 的移动历史，分支删除这个动作本身可能不在里面，但该分支上最后一次 checkout/commit 一定在，从那条记录里能看到哈希。

如果 reflog 里也找不到（比如超过保留期，或者那次是在别的路径下操作），还有两条后路：git fsck --lost-found能列出所有"悬挂提交"（没有被任何引用指向的 commit），把它们逐个git show看内容，找到目标再建分支；或者git log -g --all查所有 ref 的 reflog。这两条后路的成功率取决于 gc 有没有跑过——一旦 gc 把不可达对象清掉，就真没了。

这也引出我的一条个人原则：在删分支之前，先git log --oneline -1 <branch>记下哈希，写进当天的笔记。这个动作只要两秒，但能免掉后面半小时的心跳加速。

7.2 分离头指针：怎么进去的，怎么出来，提交怎么救

HEAD里不是ref: refs/heads/xxx而是一串哈希，就是分离头指针（detached HEAD）状态。进去的方式很多：git checkout <sha>、git checkout <tag>、git rebase过程中的中间状态、甚至某些工具的内部操作。

这个状态本身不可怕，可怕的是在里面提交。因为 HEAD 没有指向任何分支，新提交只被 HEAD 直接引用，一旦你切走，这个提交就变成不可达对象，看起来像"提交丢了"。救援办法还是git reflog——切走的那次操作会记录旧哈希，找到后git switch -c rescue <sha>把它救到一个新分支上。

想退出分离状态很简单：git switch main或git switch -。如果你在分离状态下做了修改但还没提交，切走时 Git 会警告并可能保留改动，此时要么提交到临时分支，要么 stash。

我的建议是：看到 detached HEAD 提示先别慌，也别急着切走。先git status看清楚有没有提交，有就立刻建分支。养成"看完 tag 就切回分支"的习惯，能把这类问题消灭在萌芽。

7.3 合并/ rebase 进行到一半想放弃

合并冲突解决到一半发现方向错了，git merge --abort可以回到合并前的状态（前提是合并前工作区是干净的）。如果是 rebase，对应git rebase --abort，同样要求工作区能恢复。

这两个--abort之所以能"完美回滚"，是因为 Git 在操作开始前把原始 HEAD 记在了.git/ORIG_HEAD或 rebase 的临时目录里。顺带一提，git reset --hard ORIG_HEAD是另一个通用的"回到上一次危险操作之前"的办法，它在 merge、rebase、pull 之后都能用。

如果已经提交了合并但想撤销，用git reset --hard HEAD~1回退一个提交（合并提交算一个）。注意这只适用于还没推送的情况；推过之后要用git revert -m 1 <merge-sha>生成一个反向提交，-m 1表示保留第一父链（也就是你合并进去的那条主线）。

7.4 把错误合并推上去之后

这是最需要谨慎处理的场景。原则只有一条：不要用强推去改公共历史。正确做法是git revert生成反向提交，把错误合并的影响抵消掉，历史保持可追溯。虽然图会难看一点，但所有人都能安全地pull到正确状态。

如果错误合并里夹带了不该提交的敏感内容（比如本地配置文件里带了密钥），revert是不够的，因为旧提交里内容还在。这种情况必须走"改写历史 + 全员重新克隆"的流程：先在本地把那段历史清理掉，然后通知所有协作者重新拉取，最后在托管平台上清理缓存。代价很大，所以更根本的防线是.gitignore和提交前 review——我现在的习惯是推之前一定git diff --stat origin/main扫一眼，看看这批改动涉及哪些文件，防的就是"顺手 add 了不该 add 的东西"。

最后分享一个小技巧，也是我自己用了很多年的：给git log配个别名，专门看带分支边界的历史。

git config --global alias.lg "log --graph --oneline --decorate --all -30"

配合--first-parent看主干、不带它看全貌，两个视角切换着看，分支之间的关系基本不会看错。工具本身不复杂，真正花时间的是养成"动手前先看一眼全景"的习惯——踩过的坑多了，你会发现大部分事故都不是因为不会命令，而是因为闭着眼睛敲命令。