git mv 更安全，因其自动完成重命名、暂存区更新和历史保留；避免手动操作导致的“deleted+untracked”状态、文件丢失及历史断裂。
直接用 git mv 就行，但别把它当普通 mv 用——它本质是 git rm --cached + git add 的组合操作，不加 --force 时还会检查目标路径是否已存在冲突文件。
为什么 git mv 比手动 mv + git add/git rm 更安全
Git 不记录“移动”元数据，只记录文件内容快照。手动改名后不告诉 Git，状态会变成“deleted”+“untracked”，下次 git status 显示两行，容易误删或漏提交。git mv 自动完成三件事：重命名工作区文件、从暂存区移除旧路径、把新路径加入暂存区。
- 避免因忘记
git add新路径导致提交丢失文件 - 保留文件历史（
git log --follow能追溯到原名） - 在重命名同时修改内容时，Git 能更准确计算 diff（相比先删再加）
git mv 常见报错和对应解法
最常卡在这几个地方：
-
fatal: destination exists：目标路径已有同名文件或目录，Git 拒绝覆盖。加--force可强制（慎用），或先git rm -r <target>清理 -
fatal: not under version control：源文件没被 Git 跟踪（比如刚创建未git add）。此时git mv无效，直接mv+git add <new-path> - 跨分区移动失败（Linux/macOS）：
git mv底层用的是rename(2)系统调用，不支持跨文件系统。改用git rm <old> && git add <new>
移动时要不要加 --force？什么情况下必须用
--force 不是默认行为，也不推荐无脑加。它只解决一类问题：目标路径已被 Git 跟踪，但你想用移动覆盖它（比如合并分支时重排目录结构）。
GitHub Smart Code Digest
下载
GitHub Smart Code Digest — 自动监控仓库 Commits/PR，AI 智能代码审查，生成可视化审查卡片并汇总至飞书 Wiki。适用于团队代码质量追踪和工程管理者日报/周报生成。触发词：代码审查报告、GitHub 监控、PR 审查日报、代码质量汇总、工程师日报。
- 目标是未跟踪的空目录？不用
--force，Git 允许直接移入 - 目标是已跟踪文件？加
--force后，Git 会自动git rm掉旧文件再写入新路径 - 目标是已跟踪目录且非空？
--force不起作用，得先git rm -r <target-dir>
示例：把 src/utils.js 移到 lib/helpers.js，且 lib/ 下已有 index.js 被跟踪：git mv --force src/utils.js lib/helpers.js。
移动大量文件或整个目录的实操注意点
批量移动看似方便，但 Git 对目录层级变化敏感：
- 移动整个目录（如
git mv old_dir new_dir）没问题，所有子文件历史都保留 - 但若目标目录已存在部分同名文件，Git 不会合并，而是报错——它不处理“部分覆盖”逻辑
- 想把多个文件移到同一新目录？确保该目录已存在（Git 不自动创建中间目录），或用
mkdir -p预建 - 重命名后立即
git status看一眼：正确状态应是renamed: old/path -> new/path，不是两行独立增删
真正容易被忽略的是：移动后如果立刻 git commit，这次提交里不会体现“移动”语义——它只是删旧加新。只有后续用 git log --follow --name-only 才能还原路径变更链。别指望 GitHub/GitLab 界面自动识别 rename，它们多数只显示为 delete + add。
