git reset --hard 会无条件丢弃所有未提交的本地修改并重置工作区和暂存区到指定commit，风险极高，需确认无重要未跟踪文件且已备份关键数据。
git reset --hard 会丢掉所有未提交的本地修改
这是最直接的强制覆盖方式，但风险极高：它会把工作区和暂存区全部重置到指定 commit（通常是 origin/main），所有 git status 显示为 modified、untracked 或 deleted 的文件都会被无条件还原或删除。
实操前务必确认：
- 本地没有需要保留的未 git add 的改动
- 没有重要的未跟踪文件（比如临时配置、日志、.env.local）
- 已备份关键数据（如数据库迁移文件、生成的代码）
执行命令：
git fetch origin<br>git reset --hard origin/main
git checkout -- . 和 git clean -fd 要分清作用范围
git checkout -- . 只能恢复已跟踪（tracked）文件的修改，对新增的 untracked 文件完全没影响；而 git clean -fd 是专门清理未跟踪文件和目录的——但它是不可逆的删除操作，不是“覆盖”。
典型误用场景：
- 以为 git checkout -- . 能删掉新生成的 node_modules → 实际不会动它
- 运行 git clean -fd 前没加 -n 预览 → 误删 IDE 配置或本地 mock 数据
安全做法：
git checkout -- .<br>git clean -n # 先看要删什么<br>git clean -fd # 确认无误后再执行
git pull --force 不是合法命令，别被误导
不存在 git pull --force。有人想“强制拉取并覆盖”，其实是混淆了 pull（= fetch + merge）和 reset 的语义。强行 merge 可能产生冲突甚至错误历史，尤其当本地有 commit 时，git pull 默认走 merge，不是覆盖。
正确替代方案：
- 本地没 commit：用 git fetch && git reset --hard origin/main
- 本地有 commit 但确定要丢弃：先 git log --oneline -n 5 确认 HEAD 位置，再 reset
- 想保留本地 commit 记录但同步远端代码：改用 git pull --rebase，但注意这会重写提交历史
覆盖后 submodule 状态经常被忽略
如果项目含 submodule，git reset --hard 不会自动更新子模块内容，它们仍停留在旧 commit。此时 git status 会显示 submodule 路径为 “modified”，但 git diff 看不到具体变化。
必须额外同步：
git submodule update --init --recursive<br># 如果子模块本身也有本地修改，需先清理：<br>cd path/to/submodule<br>git reset --hard<br>cd -
更稳妥的做法是把 submodule 清理也写进部署脚本，而不是依赖一次 reset 覆盖全部。
