会，git mv 通过触发重命名检测（相似度≥50%）使 git log --follow 能追溯旧路径历史；手动 rm+add 则依赖 Git 自动推断，成功率更低。
git mv 会保留提交历史吗
会，但只在 Git 认为是“重命名”而非“删除+新建”的前提下。Git 没有显式的 rename 操作，git mv 本质是 git rm --cached <old> + git add <new>，再加一层重命名检测逻辑。是否保留历史，取决于后续 git log --follow 能否连上——而这依赖于 Git 的重命名启发式算法（默认相似度阈值 50%）。
实操建议：
- 文件内容改动越小，
git log --follow <new-path>越容易追溯到旧路径 - 如果重命名同时大改内容（比如重写函数体），Git 可能判定为“新文件”，历史就断了
- 用
git log -M --oneline <new-path>查看是否触发了重命名检测（-M启用重命名发现） - 别指望
git log <new-path>默认显示旧历史；必须加--follow
git mv 和手动 rm + add 有什么区别
表面行为一致，但 git mv 是语义提示：它让 Git 知道你“有意重命名”，从而在后续 diff、log、blame 中更倾向启用重命名逻辑。手动操作则完全依赖 Git 自动推断，成功率更低。
常见错误现象：
- 手动
mv old.txt new.txt后直接git add new.txt，Git 会报告 “deleted: old.txt” + “new file: new.txt”，不标记重命名 -
git status显示两行独立变更，而不是 “renamed: old.txt -> new.txt” -
git diff --staged可能显示全量新增/删除，而非行级差异
所以，哪怕只是临时重命名，也优先走 git mv <old> <new> —— 它不保证 100% 保留历史，但提高了 Git 正确识别的概率。
跨目录移动时要注意路径和暂存状态
Git 对路径敏感，git mv 的源和目标路径必须相对于当前工作目录，且目标目录需已存在（Git 不自动创建父目录）。
使用场景举例：把 src/utils.js 移到 lib/helpers.js
- 先确保
lib/目录存在，否则报错：fatal: renaming 'src/utils.js' failed: Invalid argument - 如果
src/utils.js已被修改但未暂存，git mv会拒绝操作，提示 “working directory clean” —— 必须先git add或git restore --staged保持暂存区干净 - 移动后执行
git status，应看到 “renamed: src/utils.js -> lib/helpers.js”，不是两行独立变更 - 若目标路径已存在同名文件且已跟踪，
git mv会失败，避免意外覆盖
重命名后如何验证历史是否连得上
不能只看 git log，要针对性验证。最可靠的方式是用 --follow 加具体路径查，再对比旧路径日志。
实操步骤：
- 重命名后运行：
git log --oneline --follow lib/helpers.js—— 如果能看到早于重命名的提交，说明连上了 - 对比：
git log --oneline src/utils.js（重命名前路径），确认最后一条提交和上面结果的首条一致 - 用
git show <commit-hash>:lib/helpers.js检查某次旧提交里该路径是否存在内容（若报错 “path not found”，说明那会儿还没这路径） - 注意：
git blame默认不跨重命名，要用git blame -M lib/helpers.js才可能看到旧文件里的行作者
真正容易被忽略的是：重命名操作本身是一次提交变更，但 Git 的历史追溯能力高度依赖后续命令是否带对参数。没加 --follow，就等于没重命名。
