`git merge --squash` 后为什么看不到原始提交记录？

Question

**问题：** 执行 `git merge --squash ` 后，为什么在主分支的历史中完全看不到被合并分支的原始提交记录（如 commit hash、作者、提交信息等）？这是否意味着提交丢失了？ **简析：** `--squash` 并非真正的合并（不创建 merge commit），而是将目标分支的所有变更**压缩为一个暂存状态**，需手动 `git commit` 才能提交。此时 Git 仅应用变更内容，**不保留任何原始提交的元数据**（SHA-1、author/committer 信息、提交树结构、父提交指针等）。历史中只会出现你新提交的单个 commit，原始分支的提交仍存在于 reflog 和对象库中（未被 GC 前可恢复），但已脱离主分支的可追溯历史链。这与 `git merge`（保留完整提交图谱）或 `git rebase`（线性重放但可选保留 author）有本质区别。常见误解是“合并失败”，实则是设计使然——用于简化历史、避免污染主干，但牺牲了溯源能力。

Answer 1

```html

一、现象层：为什么 git merge --squash 后主分支“看不见”原分支提交？

执行 git merge --squash feature-branch 后，git log 在 main 分支上仅显示一个新提交（如 abc1234），而 feature-branch 的全部 7 个原始提交（def5678、ghi90ab…）彻底消失于线性历史视图中。这不是 Git 的 bug 或误操作，而是其核心设计逻辑的必然结果——--squash 本质是“变更内容搬运”，而非“历史关系继承”。

二、机制层：Git 内部如何处理 --squash？

• 无 commit 对象生成：不创建 merge commit，也不保留任何父提交指针（parent 字段为空）；
• 元数据清零：author/committer 信息默认继承当前用户（非原作者），commit message 需手动编写，SHA-1 完全重算；
• 树对象重建：Git 将目标分支 tip 的 tree 与当前 HEAD 的 tree 做三路 diff，生成全新暂存区（index），再由用户触发 git commit 创建独立 commit 对象。

三、数据层：原始提交真的“丢失”了吗？

位置	是否可见	可恢复性	说明
reflog（git reflog show main）	✅ 是（短期）	高（默认 90 天）	记录 HEAD@{1} 等快照，含被 squash 分支的 SHA
.git/objects/ 对象库	✅ 是（底层）	极高（GC 前永久）	原始 commit 对象仍存在，但成为“悬空对象”（dangling）
git log --all --grep="keyword"	❌ 否（需额外参数）	中（依赖 reflog 或 fsck）	默认不遍历未引用对象，需 --unreachable 或 git fsck --lost-found

四、对比层：三种集成策略的历史语义差异

graph LR A[feature-branch] -->|git merge| B[main
→ merge commit
→ 保留所有 parent 指针
→ 完整 DAG 图谱] A -->|git rebase| C[main
→ 线性重放
→ author 可保留
→ committer 为 rebaser] A -->|git merge --squash| D[main
→ 单一新 commit
→ 无 parent 关系
→ 元数据完全重写]

五、工程层：何时该用、何时该禁用 --squash？

✅ 推荐场景：
– PR/MR 提交审查后需“原子化交付”（如 CI/CD 流水线要求单 commit 触发部署）；
– 外部贡献者提交质量参差（大量 WIP、fixup、格式错误 commit）；
– 主干分支（如 release/v2.0）需严格控制历史可读性与审计粒度。

❌ 反模式场景：
– 团队依赖 git blame 追溯代码作者（原始 author 信息已不可逆丢失）；
– 需要 git bisect 精确定位引入 bug 的具体提交（squash 后无法二分到原始变更点）；
– 合规审计要求完整变更链存证（GDPR/SOC2 等场景下，元数据缺失构成风险）。

六、恢复层：当误删 squash 前分支时的抢救路径

1. 立即执行 git reflog show feature-branch 或 git reflog show main 查找最后引用点；
2. 若 reflog 存在，运行 git branch recover-feature <sha> 重建分支；
3. 若 reflog 已清理，用 git fsck --lost-found 扫描 dangling commit，并通过 git show <sha> 人工识别内容；
4. 最终通过 git cherry-pick <sha1> <sha2> ... 或 git rebase --onto 重建可追溯历史。

七、进阶层：如何在保留简洁性的同时增强溯源能力？

折中方案示例（CI 脚本中自动注入）：

git merge --squash feature/login
git commit -m "feat(auth): implement login flow [SQUASHED FROM: feature/login@def5678, ghi90ab]" \
  --author="Original Author <[e-mail]>" \
  --date="2024-03-15T14:22:00+08:00"

该方式虽不能恢复 commit 对象本身，但将关键元数据（分支名、原始 SHA、作者、时间）编码进新 commit message，使 git log --grep 和审计工具仍可关联上下文。

```