git reset --hard origin/main 会丢弃三类内容：已提交但未推送的本地提交、已暂存但未提交的修改、以及未跟踪的新文件（需配合 git clean）；.gitignore 排除的文件不受影响。
git reset --hard origin/main 会丢弃哪些内容？
这条命令会彻底清除三类东西：git reset --hard 之后，本地工作区和暂存区所有改动消失，包括已跟踪文件的修改、新增但未 git add 的文件、以及本地分支上比远程多出的提交记录。它不碰 .gitignore 里声明的文件（比如 node_modules），除非你额外加 git clean -fdx。
常见错误现象：执行后 git status 显示 nothing to commit, working tree clean，但发现 dist/ 或 logs/ 还在——那是被 .gitignore 排除的，reset 不管它们。
- 已提交但未推送的本地 commit → 彻底消失，reflog 里还能查到（默认保留 30 天），但别人 push 后你就找不回了
- 已
git add但没commit的修改 → 清空 - 没
git add过的新文件（如临时脚本、测试数据）→ 仍在磁盘，需靠git clean手动删
git clean -fd 和 -fdx 的区别在哪？
git clean -fd 只删未被 Git 跟踪的文件和目录；git clean -fdx 还会删 .gitignore 里列出的路径（比如 build/、__pycache__/）。后者才是“不留痕迹”的关键一步，但风险也更高。
使用场景：CI 构建后清理、本地开发环境重置、或确认远程代码就是唯一权威源时。
- 加
-n先预览：运行git clean -fdn看它打算删什么，再决定是否真删 - Windows 用户注意：
git clean -fd在 PowerShell 里可能因权限失败，建议用 Git Bash 执行 - 如果项目用了子模块，
git clean不处理它们；得单独跑git submodule foreach --recursive git clean -fdx
为什么不用 git pull --force？
git pull --force origin main:main 看似简洁，但它本质是 git fetch + git merge（或 rebase），即使加 --force，Git 仍会尝试合并逻辑，可能触发冲突提示或意外保留部分本地状态。它不等价于“完全覆盖”。
真正强制同步只有两条路：要么 reset --hard + clean，要么删整个本地目录重新 git clone。前者快，后者最干净。
-
git pull --force实际调用的是git fetch后的更新 ref 操作，不是重置工作区，所以改过的文件可能还在“未暂存”状态 - 某些 Git 版本（如 2.40+）对
--force参数做了限制，默认禁用，需显式配置pull.ff = only才能绕过 - 如果你看到
fatal: Not possible to fast-forward, aborting.，说明pull --force已失效，必须换reset方案
如何验证“不留痕迹”已达成？
执行完 git reset --hard origin/main 和 git clean -fdx 后，不能只信 git status。要交叉验证：
- 运行
git diff origin/main—— 应该无任何输出 - 检查
git log --oneline -n 5，前几条 commit hash 必须和git log origin/main --oneline -n 5完全一致 - 手动进目录看有没有残留文件：比如
ls -la | grep '^d' | grep -v '\.git'，确认没多出不该有的目录 - 如果项目有生成文件（如
package-lock.json），git clean -fdx会删掉，但npm install后内容可能和远程不同——这不是 Git 的问题，是构建产物本身不可重现
最容易被忽略的是：reflog 依然存着旧 commit 的 hash，只要没过期（默认 90 天 for HEAD），git reflog 就能翻出来。真要“不留痕迹”，得手动 git reflog expire --expire=now --all，但这会影响所有分支的恢复能力，一般没必要。
