Git 三个状态为什么会不一致？

① 先把后文会反复出现的词认清楚

先认词：这一课最容易卡住的不是命令，而是把对象身份、引用位置、工作目录状态和真实运行版本混成“代码版本”。

② 现在再看这段材料到底在说什么

一句话：Git 的“状态不一致”不是一个 bug，而是它允许多个引用、多个工作区和多个历史分支独立演化的直接结果。真正的问题是：你有没有把每个状态变量说清楚。

例如，“服务器已经 fetch 最新 main”只改变了 R 里的 origin/main；它不会自动移动当前 HEAD，不会自动改 index/working tree，更不会自动重建 Docker 镜像或重启生产进程。于是完全可能同时出现：

GitHub main       = 84382576
server origin/main= 84382576   # 服务器已经知道远端在哪
server HEAD       = c5e35ae    # 服务器实际 checkout 仍在别处
working tree      = clean      # 但相对 c5e35ae 没有未提交改动
runtime image     = ???        # 还需要单独证明

clean 的严格含义为什么很窄

简化地说，如果把当前 HEAD 快照记作 T_H、index 快照记作 T_I、工作区可跟踪内容记作 T_W，那么“没有 staged/unstaged 修改”要求它们在相关比较上相等：

$$T_H=T_I=T_W$$

但这个等式里根本没有 origin/main。所以 clean 与 up-to-date 是两个正交命题：一个回答“有没有本地未提交变化”，另一个回答“当前 commit 与某个远端 ref 的图关系是什么”。

③ 概念关系与最小知识闭包

最小知识闭包 1：分支关系是偏序，不是时间排序

设提交图为 DAG G=(V,E)，边从子 commit 指向父 commit。定义 B ≼ A 表示从 A 沿父边可以到达 B，也就是 B 是 A 的 ancestor。这个关系是偏序：有些 A、B 互不为祖先，它们发生了真正分叉。

因此“哪个 commit 时间更晚”不能替代“哪个包含哪个”。fast-forward 是否可能，只取决于祖先关系：如果当前 commit 是目标 commit 的 ancestor，就可以只移动 ref；否则需要 merge、rebase、cherry-pick 或其他显式集成。

最小知识闭包 2：ahead / behind 的数学含义

给定两个 tips A、B 和共同基线 M，粗略可以理解：

$$\mathrm{ahead}(A,B)=\left|\mathrm{Reach}\right(A)\setminus \mathrm{Reach}(B\left)\right|$$

$$\mathrm{behind}(A,B)=\left|\mathrm{Reach}\right(B)\setminus \mathrm{Reach}(A\left)\right|$$

git merge-base A B
git rev-list --left-right --count A...B
git log --oneline --left-right A...B

所以“server 比 GitHub behind 631、ahead 1”和“frontend 比 GitHub behind 621、ahead 66”描述的是两组不同集合差，完全可以同时成立。

最小知识闭包 3：fetch、pull、switch、merge 分别改变什么

最小知识闭包 4：为什么 reflog 不是备份策略

reflog 记录本地 ref/HEAD 曾经指向哪里，很多误操作后确实能用于恢复。但 reflog 有保留期限、是本地性的，也可能在垃圾回收后失去对象。成熟流程应该在危险操作前主动建立明确 branch/tag 或远端备份 ref，而不是事后祈祷 reflog 还在。

git branch backup/server-20260831 c5e35ae
git branch backup/frontend-20260831 a0580dec
git show --stat backup/server-20260831
git log --oneline origin/main..backup/server-20260831

最小知识闭包 5：冲突数量不是“谁对谁错”

48 个冲突文件只说明 Git 无法自动合并那些路径/片段。它既不证明前端分支错误，也不证明 main 应该被覆盖。冲突解决是一个语义判断：在最新 main 的架构约束上，哪些旧改动仍代表你真正想保留的行为？

最小知识闭包 6：Git 收敛和生产收敛是两件事

设最终权威 commit 为 M。Git 收敛可以要求 local main = origin/main = GitHub main = M；但生产收敛还要增加 runtime_source = M 或至少可验证的 artifact digest → M 映射。否则你会得到“仓库看起来全对，线上仍旧”的假阳性。

最小知识闭包 7：三方合并为什么需要 merge base

Git 合并不是简单比较 A 和 B 两份最终文件，然后决定谁覆盖谁。典型三方合并会同时看共同祖先 M、当前分支 A、待合并分支 B：分别计算 M→A 与 M→B 的变化，再尝试组合。只有两边对同一语义区域做了无法自动协调的修改时，才产生冲突。

这解释了一个重要现象：两个分支最终文件看起来差异巨大，也不一定产生很多冲突；反过来，即使只改了少量行，只要双方碰到同一上下文，也可能冲突。冲突数量因此不能直接当“分支质量分数”。

最小知识闭包 8：commit identity 和 patch identity 不是一回事

rebase、cherry-pick 会创建新的 commit，即使代码变化“看起来一样”，commit ID 也通常不同，因为父提交、元数据等发生变化。因此判断“这个修复是否已经以等价补丁进入 main”有时不能只用 SHA 相等，还需要看 patch、文件 diff、测试和功能证据。

这也是为什么大规模历史整理后，旧分支可能显示很多“独有 commits”，但其中部分语义已经以新 commit 形式进入主线。此时不能机械地把所有旧 commit 再 cherry-pick 一遍，否则可能重复应用同一修改。

最小知识闭包 9：删除 branch 为什么不等于删除历史

branch 只是 ref。删除 branch 主要删除一个名字；只要其 commit 仍被其他 refs、reflog 或对象可达关系引用，历史对象仍可能存在。但如果某一串 commit 只有这个 ref 能稳定到达，删除后就降低了可发现性和可恢复性，未来垃圾回收也可能清理不可达对象。

所以“这个分支看起来没用了”不是删除依据。先用 git branch --merged、git log main..branch、比较 patch/功能证据确认没有独有价值，再做清理。

④ 把真实案例重新还原

案例数据

共同基线：36b470e7

GitHub main：84382576
  └─ 从共同基线独有 +621 commits

本地 frontend：a0580dec
  └─ 从共同基线独有 +66 commits
  └─ 与最新 main 试合并：48 个冲突文件

106 server HEAD：c5e35ae
  └─ 相对某比较基线有独有 +1 commit

106 origin/main：84382576
  └─ 已 fetch 到 GitHub main

另有临时 worktree：0fb8cad7
  └─ 相对 main 落后若干 commit

第一问：服务器到底“同步了没有”？

答案必须拆成三句话：服务器的 origin/main 已同步到远端观察结果；服务器的当前 HEAD 没有同步到 main；实际运行服务版本未知，需要继续查构建/容器/进程。只说“同步了”或“没同步”都过于粗糙。

第二问：为什么不能先在 106 上 reset --hard？

因为服务器有一个独有 commit c5e35ae。在确认这个 commit 的内容、价值和备份引用之前，hard reset 会把当前分支直接移到另一个点并覆盖工作区/index。即使对象暂时可通过 reflog 找回，也是在主动降低可恢复性。

第三问：前端 66 个 commit 应该怎么进 main？

不是把“66 个 commit 全保留”作为目标，而是把“这些历史中仍然需要的产品/工程行为”作为目标。先从最新 main 创建 integration 分支，在非生产环境做合并或重放，处理冲突后跑测试。若历史非常嘈杂，也可以通过分段 cherry-pick、重新整理 commit 或将功能重新实现到新架构，但必须保留审计线索。

第四问：临时 worktree 为什么也要清点？

因为每个 worktree 有自己的 HEAD/index/working tree。主目录 clean 不代表临时 worktree 没有独有未提交改动。收敛前应执行：

git worktree list --porcelain
git status --short
git stash list
git branch --all --verbose --no-abbrev

再分别进入需要检查的 worktree 查看状态。

第五问：怎么把事实记录成机器可验证证据？

# refs
git rev-parse HEAD
git rev-parse refs/remotes/origin/main

# 图关系
git merge-base HEAD origin/main
git rev-list --left-right --count HEAD...origin/main

# 独有历史
git log --oneline origin/main..HEAD
git log --oneline HEAD..origin/main

# 未提交状态
git status --porcelain=v1
git diff
git diff --cached

这些命令分别回答“指针在哪里”“图关系是什么”“谁有独有 commits”“工作区/index 是否有独有未提交状态”，比一句“看起来差不多”更适合 Agent/CI 自动验收。

⑤ 概念如何映射到现实

危险命令按“是否会销毁当前可见状态”分类

给 AI Coding Agent 的验收合同

1. 不允许根据“branch 名相同”宣称版本一致。
2. 必须报告 HEAD / local main / origin/main 的完整 SHA。
3. 必须报告 ahead/behind 的比较对。
4. 发现独有 commit、stash、dirty worktree 时禁止先 hard reset。
5. 集成在非生产分支完成并通过测试后，才允许更新 canonical main。
6. 部署完成必须读回 runtime version / image digest 和 health。

⑥ 现在把它当成一道题

⑦ 分级提示，最后就是实际答案

git status --porcelain=v1
git rev-parse HEAD
git rev-parse main
git rev-parse origin/main
git worktree list --porcelain
git stash list
git branch --all --verbose --no-abbrev

git merge-base HEAD origin/main
git rev-list --left-right --count HEAD...origin/main
git log --oneline origin/main..HEAD

git branch backup/server-c5e35ae c5e35ae
git branch backup/frontend-a0580dec a0580dec

# 如果需要跨机器恢复，应把明确 backup ref 推到受控远端
# git push origin backup/server-c5e35ae
# git push origin backup/frontend-a0580dec

git fetch origin
git switch -c integrate/frontend-20260831 origin/main

# 服务器独有热修仍有价值时，先显式重放
git cherry-pick c5e35ae

# 再集成前端历史（示意）
git merge backup/frontend-a0580dec

git fetch origin
git switch main
git merge --ff-only origin/main

git rev-parse HEAD
git rev-parse origin/main
git status --porcelain=v1

# 例：应用自己暴露版本
curl -sS https://service.example.com/version

# 例：Docker
docker inspect --format '{{.Image}}' app
docker image inspect IMAGE --format '{{json .RepoDigests}}'

# 再做业务 smoke / health
curl -fsS https://service.example.com/health