- 已经会基本提交和分支操作的开发者
- 想理解命令边界与风险的人
Command Reference
git mv
用于重命名或移动已跟踪文件，帮助你把文件系统变化和暂存区状态一次保持一致。
- 知道工作区、暂存区、提交的基本关系
- 能读懂 `git status` 和简单历史图
- 误把本地整理命令用到共享历史
- 在没确认恢复路径前直接继续改写历史
git mv 把文件移动或重命名，并把这次变化一并放进暂存区。
常见写法
git mv old-name.ts new-name.ts
git mv docs/guide.md docs/intro.md
什么时候值得用
- 你希望文件移动和 Git 暂存保持一步完成
- 你在大规模重命名目录，希望操作更一致
它和手动 mv 的关系
手动移动文件后再 git add -A 也可以。Git 最终会通过内容相似度推断 rename。git mv 的价值主要是让命令更直接、暂存状态更清晰。
常见误区
Git 底层真的保存“重命名对象”吗
不完全是。Git 更关注内容和路径变化，rename 更多是比较和展示层面的结果。
git mv 比普通 mv 更“高级”
它主要是更方便，不是完全不同的底层机制。
这条命令在流程里解决什么问题
git mv 在文件系统和暂存区两个层面同时操作：它把文件从源路径移到目标路径（工作区层面），并把这次移动记录到索引中（暂存区层面）。它解决的是"让文件移动和 Git 暂存一步到位"的问题，避免手动 mv 后再 git add 和 git rm。
典型用例
- 重命名文件并自动暂存（
git mv old.ts new.ts），一步完成文件系统移动和 Git 暂存。 - 移动文件到新目录（
git mv docs/guide.md docs/intro.md），适合整理项目结构。 - 大规模重命名目录时保持暂存状态清晰，
git status会直接显示为 renamed 而非 deleted + added。
图例理解
源文件路径目标文件路径索引中的跟踪状态
工作区中新路径的文件索引中已暂存的 rename 记录
Git 底层并不存储重命名对象，而是通过内容相似度推断 rename，所以手动 mv + add -A 也能达到相同效果。
特殊情况与边界
git mv只对已跟踪的文件生效，对新文件使用会报错。- 目标路径已存在时操作会失败，除非使用
-f强制覆盖。 - Git 底层通过内容相似度来识别 rename，所以
mv+git add -A和git mv在最终提交层面效果一致——git mv主要胜在一步到位、状态更清晰。 - 移动带有未暂存改动的文件时，改动会随文件一起迁移，不会丢失。