git clean -f 只删除工作区中未被 Git 跟踪的文件（即 git status 显示为 untracked 的文件），不删已暂存或已提交文件，也不删 .gitignore 中忽略的文件或目录；加 -d 才删未跟踪目录，加 -x 才删被忽略的文件。
git clean -f 会删掉哪些文件
git clean -f 只删除工作区中「未被 Git 跟踪」的文件，也就是 git status 显示为 untracked 的那些。它不会碰已暂存（staged）或已提交（committed）的文件，也不会删掉 .gitignore 里明确忽略但实际存在的目录——除非加 -d 参数。
常见误操作场景：刚 checkout 到新分支，执行 git clean -f 后发现 build/ 或 node_modules/ 没被删——因为这些通常在 .gitignore 里，而 -f 默认不处理被 ignore 的条目。
- 加
-x：强制清理所有 untracked 文件，包括.gitignore里声明的（比如临时日志、编译产物） - 加
-d：连 untracked 目录也一并删掉（git clean -f默认只删文件） - 加
-n（dry-run）：先预览要删什么，强烈建议每次执行前都跑一遍git clean -n -fdx
清理前必须确认当前分支状态
Git 不会阻止你在任意分支上运行 git clean，但它只管工作区，不管分支指针。如果你在 feature/login 分支上删了 src/api/ 下一堆新写的未 commit 文件，切回 main 后它们也不会回来——因为根本没进过暂存区或历史。
所以真正要防的不是“删错分支”，而是“删错当前分支正在写的草稿”。尤其注意：
-
git checkout切分支时，如果目标分支没有某个文件，而当前工作区有该文件且未跟踪，它会保留——这容易让人误以为“还在原分支”，其实已经混了 - 用
git status --ignored看被忽略但存在的文件，确认它们是否真可删 - 如果刚从别人 PR 拉了代码、跑了
npm install，node_modules/是 untracked 但显然不能删——这时候git clean -fd就很危险
git clean 和 git reset --hard 的区别在哪
git reset --hard 是重置「已跟踪文件」到 HEAD 状态，会丢弃你对 tracked 文件的修改；而 git clean 只动 untracked 文件，对已跟踪文件完全无感。两者常被一起用，但目的完全不同。
批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。
典型组合流程：
-
git reset --hard：撤回所有已跟踪文件的本地修改 -
git clean -fd：清掉新增的 untracked 文件和目录 - 合起来才等于“回到干净的 commit 状态”
漏掉其中一步，就可能残留修改或文件。比如只跑 git reset --hard，但忘了 git clean，build/ 目录还在；反之只跑 git clean，.env 文件改了却没还原。
Windows 下 git clean 遇到 Permission denied 怎么办
常见于 node_modules/ 或某些 IDE 自动生成的 .idea/ 目录——进程锁住文件，Git 没权限删。错误信息通常是：fatal: cannot delete 'node_modules/xxx': Permission denied。
- 先关掉 VS Code、WebStorm、终端里跑着的 dev server（比如
npm run dev） - 用 Windows 任务管理器检查是否有 node.exe、java.exe 占着目录
- 改用 PowerShell 以管理员身份运行？不推荐——治标不治本，反而可能删掉系统级文件
- 更稳的办法：加
-e忽略特定路径，例如git clean -fd -e "node_modules/"，再手动删或重装依赖
真正麻烦的是那些被编辑器长期占用又不释放句柄的文件，删之前多看一眼 git clean -n -fd 输出，别让自动清理变成“删一半卡死”。
