Git replace 对象视图：内容看起来换了，原来的对象为什么仍能读到
同一个对象编号，在一个仓库里读出新的内容，禁用某个选项又能读出旧内容。第一反应可能是对象损坏，但还应检查替换引用。Git replace 可以给对象访问建立一层替代关系，让很多命令看到另一个对象的内容。
这项能力可用于本地调查或历史实验，但它不是把原对象原地改写。理解这一点最直接的办法，是建立两个很小的内容对象，明确记录它们的编号，再分别查看替换开启与关闭时的结果。
只替换临时仓库里的两个 blob
把代码存为 demo.sh，通过 bash demo.sh 运行。本文在 Git 2.52.0、Bash 5.2.37 验证。脚本创建独立临时仓库，不建立远程连接，不修改已有分支，也不写全局配置。实验结束会清理自己创建的目录。
AI概念示意图：表现本文的抽象关系，并非软件截图或真实运行结果。
set -euo pipefail work=$(mktemp -d) trap 'rm -rf -- "$work"' EXIT cd "$work" git init -q old=$(printf 'original\n' | git hash-object -w --stdin) new=$(printf 'replacement\n' | git hash-object -w --stdin) [[ "$old" != "$new" ]] [[ "$(git cat-file -p "$old")" == original ]] git replace "$old" "$new" [[ "$(git replace -l)" == "$old" ]] visible=$(git cat-file -p "$old") raw=$(git --no-replace-objects cat-file -p "$old") [[ "$visible" == replacement ]] [[ "$raw" == original ]] [[ "$(git rev-parse "refs/replace/$old")" == "$new" ]] git replace -d "$old" >/dev/null [[ -z "$(git replace -l)" ]] [[ "$(git cat-file -p "$old")" == original ]] [[ "$(git cat-file -p "$new")" == replacement ]] printf 'normal=%s disabled=%s restored=original\n' "$visible" "$raw" printf 'replace checks passed\n'
引用负责指路，两个对象都还在
hash-object 把两段文字写成不同的 blob。创建替换关系以后，对旧编号执行普通 cat-file 会读到 replacement，加上全局选项 --no-replace-objects 则读到 original。实测输出同时包含这两个单词，证明不是单纯把屏幕上的文字改了一遍。
替换引用位于 refs/replace 命名空间，示例验证旧编号对应的引用确实指向新编号。原编号仍标识原对象，读取命令只是根据替换关系采用另一个对象的视图。调查时记录替换引用，比只保存一条 cat-file 输出更完整。
删除这条替换引用之后，普通读取重新显示 original，而新对象本身仍能单独读取。删除映射与删除对象是两回事。这里删除的是刚刚创建的实验引用，不是清理真实仓库中未知用途的引用。
同样的编号，需要说明读取上下文
命令行里的禁用选项放在 git 后、子命令前，这是全局选项的位置。若写在 cat-file 的参数里，可能被当成不支持的子命令选项。需要比较视图时，保持对象编号相同，只切换这一项，才能把影响范围说清。
默认情况下，替换对象与原对象要求类型一致。本例两边都是 blob，避免引入提交父链与目录树结构。虽然命令还提供更高级的替换方式，但不宜把一次内容观察实验直接扩展到生产分支的历史手术。
替换引用会影响多种 Git 命令，却不是所有操作都以相同方式采用它。官方文档对可达性遍历等操作列有例外。因此不能根据一次读取结果推断打包传输、检查或回收行为，也不能把这个机制当作删除敏感历史的办法。
与同事对照异常时，可以先列出替换引用，再在禁用替换的条件下重复只读命令。如果两次结果不同，说明本地解释环境是重要线索。不要急于重写分支、强制推送或重置工作区，先确认真正要保存或修复的对象。
需要长期保留研究结果时，应明确记录原编号、新编号、替换目的和验证命令，并说明其他仓库是否具备同样的引用。仅贴一张日志截图无法表达这层关系。本教程的目标是建立可重复的对照方法，而不是把替换视图当成正式发布流程。
