一套完整、可复现、一步步“打脸直觉”的示例。
一、目标：你将亲眼看到这件“反直觉”的事
两个分支：
commit 几乎一模一样
中间一个分支多了一个 commit
后面的 commit 又完全一样（SHA 都一样）
并且你会彻底理解为什么这是合理的。
二、示例一：最小可复现 Git 历史（强烈建议你本地试）
1️⃣ 初始化仓库
mkdir git-branch-mindfuck
cd git-branch-mindfuck
git init
2️⃣ 创建初始提交
echo “A” > file.txt
git add .
git commit -m “A”
3️⃣ 再来两个提交（公共历史）
echo “B” >> file.txt
git commit -am “B”
echo “C” >> file.txt
git commit -am “C”
现在历史是：
A ── B ── C
4️⃣ 在 C 这里分叉一个分支
git branch feature
此时：
main, feature
↓
A ── B ── C
5️⃣ feature 分支多走一步（关键）
git checkout feature
echo “X” >> file.txt
git commit -am “X (only in feature)”
历史变成：
main: A ── B ── C
feature: A ── B ── C ── X
6️⃣ 回到 main，继续提交（你直觉会崩的地方）
git checkout main
echo “D” >> file.txt
git commit -am “D”
echo “E” >> file.txt
git commit -am “E”
现在：
main: A ── B ── C ── D ── E
feature: A ── B ── C ── X
7️⃣ 把 main 合并到 feature
git checkout feature
git merge main
没有冲突，秒合并。
8️⃣ 看图（关键时刻）
git log --oneline --graph --decorate --all
你会看到类似：
- ffffff (feature) Merge branch ‘main’
|
| * eeeeeee E
| * ddddddd D - | xxxxxxx X
|/ - ccccccc C
- bbbbbbb B
- aaaaaaa A
三、现在回答你原来的问题
是不是同一个分支？
❌ 不是
为什么后面的 commit 完全一样？
✅ 因为：
D 和 E
父 commit 一样
内容一样
提交顺序一样
👉 所以 SHA 一样
四、核心原理（这是你真正要吃透的）
1️⃣ Git 分支是什么？
分支 ≠ 一条线
分支 = 一个指向 commit 的指针
main → E
feature → Merge Commit
2️⃣ Commit 的本质是什么？
一个 commit 的 SHA 由这几样东西决定：
父 commit 的 SHA（极其重要）
文件快照（内容）
提交信息
author / committer（时间不同通常就不同）
👉 只要父链相同，后面就能“完全一样”
3️⃣ “多一个 commit”不会污染后续历史
你脑子里想的是：
多一个 commit = 分支已经“脏了”
但 Git 的真实世界是：
历史是 DAG（有向无环图），不是一维时间线
X
/
C ── D ── E
X 只是一个旁枝，不影响主干继续前进。
五、判断“是不是同一个分支”的唯一正确方式
记住这个命令：
git show-branch --sha1-name main feature
或者更狠一点：
git merge-base main feature
👉 merge-base 是“最近共同祖先”
只要你看到：
共同祖先一样
但 HEAD 不一样
那就是两个不同分支
六、你现在已经跨过了哪道坎？
你刚刚理解的是：
“Git 不是按时间思考的，而是按指针 + 父子关系”
这是：
rebase 能用对 / 用错的分水岭
看 Git 图不再迷路的分水岭
技术负责人 vs 普通使用者的分水岭
下一步（如果你愿意）
我可以继续带你玩一个更狠的：
🔥 rebase 之后：
commit 内容一样
message 一样
顺序一样
但 SHA 全变了
然后教你肉眼一眼分辨“被 rebase 过的历史”。
你要不要继续？
