Git clean 清除未跟踪 PyTorch 文件
在深度学习项目的日常开发中，尤其是使用 PyTorch 进行模型训练时，工作目录很容易变得“臃肿不堪”。每次运行实验都会生成一堆文件：模型检查点.pt或.pth、日志.log、Jupyter 的临时备份__pycache__/和.ipynb_checkpoints/……这些文件虽然对当前调试有用，但一旦积累起来，不仅占用空间，还容易干扰版本控制和团队协作。
更麻烦的是，在远程服务器或容器环境中（比如基于 PyTorch-CUDA 镜像搭建的开发环境），我们往往希望快速恢复一个“干净”的项目状态——既不想手动一个个删文件，又怕误删重要数据。这时候，git clean就成了不可或缺的利器。
不过别急着敲git clean -fxd，这个命令一旦执行，删掉的可就真找不回来了。Git 不会记录未跟踪文件的历史，所以它也无法帮你恢复。关键在于：怎么用得安全、清得明白、理得彻底？
我们先从最常见的场景说起：你刚跑完一轮实验，目录里多了十几个.pth模型文件、几条日志、还有 Jupyter 自动生成的一堆缓存。现在你想提交本次代码更新，但显然不能把这些中间产物也塞进仓库。理想的做法是只保留核心脚本和配置文件，其他一概清理。
此时，git clean正好派上用场。
它的基本逻辑很简单：扫描当前工作区中所有未被 Git 跟踪的文件，并按需删除。所谓“未被跟踪”，指的是那些从未被git add过的文件。而 Git 本身能区分三类状态：
- 已追踪（Tracked）：已经被提交或暂存；
- 未追踪（Untracked）：新创建但没加到 Git；
- 忽略（Ignored）：在
.gitignore中列出、明确不需要管理的文件。
默认情况下，git clean只处理“未追踪且未被忽略”的文件。也就是说，即使你在.gitignore里写了*.pth，这类文件也不会被自动清除——除非你主动加上-x参数。
这也带来了灵活性：你可以把那些确定不需要纳入版本控制但偶尔有用的文件（比如本地日志）放进.gitignore，平时不清理；而在真正需要“彻底打扫”时，再通过-x把它们一起清掉。
为了防止手滑，Git 设计了一个非常实用的安全机制：必须显式使用-f才能执行删除操作。换句话说，哪怕你写了git clean，如果不加-f，系统也不会动任何文件。这就像一把锁，逼你多想一步。
更聪明的做法是，第一步永远先用-n做一次“模拟运行”：
git clean -n输出可能是这样的：
Would remove __pycache__/model.cpython-38.pyc Would remove checkpoints/model_epoch_10.pth Would remove training.log Would remove .ipynb_checkpoints/train-checkpoint.ipynb看到结果后再决定是否真的清理。这种“预览 → 确认 → 执行”的流程，能极大降低误删风险。
当你确认无误后，就可以执行实际清理了：
git clean -f如果还想连同.gitignore中定义的忽略文件一并清除（例如编译产物、IDE 配置等），可以加上-x：
git clean -fx注意！这一招很猛，可能会把你原本想留下的某些本地配置也删了，务必谨慎。
另外，如果你发现有些空目录残留（比如空的checkpoints/或logs/），可以用-d来递归删除未被追踪的目录：
git clean -fd组合起来，最彻底的清理方式就是：
git clean -fxd这会删除：
- 所有未跟踪文件；
- 包括被.gitignore忽略的文件；
- 所有未被追踪的空目录。
建议的操作顺序是：-n→-f→-fd→-fxd，逐步推进，每一步都检查一下结果。
顺便提一句，.gitignore的合理配置也是整个清理策略的关键环节。一个典型的 PyTorch 项目.gitignore应该包含以下内容：
# PyTorch outputs *.pth *.pt *.ckpt *.bin # Logs *.log *.out # Caches __pycache__/ *.pyc # Jupyter .ipynb_checkpoints/ *.ipynb # Checkpoints and outputs checkpoints/ runs/ outputs/ logs/ # OS & Editor files .DS_Store Thumbs.db .vscode/ .idea/有了这份清单，配合git clean，就能实现“精准打击”，既不会漏掉垃圾文件，也不会误伤核心资源。
当然，这套流程之所以高效，还得益于现代深度学习开发环境的标准化趋势——比如 PyTorch-CUDA 官方镜像的普及。
以pytorch/pytorch:2.7-cuda11.8-devel为例，这是一个为 GPU 加速计算优化的 Docker 镜像，集成了 PyTorch 2.7、CUDA 11.8、cuDNN 以及完整的 Python 科学计算生态（如 NumPy、Pandas、Jupyter Lab）。开发者无需再为驱动兼容、库版本冲突等问题头疼，只需一条命令即可启动完整环境：
docker run -it \ --gpus all \ -p 8888:8888 \ -v $(pwd):/workspace \ pytorch/pytorch:2.7-cuda11.8-devel这条命令做了几件事：
---gpus all：启用宿主机上的所有 GPU；
--p 8888:8888：将容器内的 Jupyter 服务暴露到本地浏览器；
--v $(pwd):/workspace：将当前目录挂载进容器，实现代码实时同步。
启动后，你可以在 Jupyter Notebook 中直接运行：
import torch print(torch.cuda.is_available()) # 输出 True 表示 GPU 可用一切正常的话，接下来就可以开始训练模型了。
随着训练进行，各种输出文件逐渐堆积。等实验结束，想要回归初始状态？不用重启容器，也不用手动删除文件。回到终端，进入项目根目录，执行：
git clean -fd瞬间恢复清爽。
这种“环境不动，只清数据”的模式特别适合 MLOps 实践：环境由镜像保证一致性，数据由 Git 和清理策略管理生命周期。无论是个人复现实验，还是团队协同开发，都能大幅提升可复现性和工程规范性。
举个真实案例：某团队曾因成员本地 CUDA 版本不一致导致训练速度差异巨大，排查良久才发现问题根源。后来统一采用 PyTorch-CUDA 镜像后，这类问题彻底消失。再加上定期使用git clean -n检查并清理未跟踪文件，项目目录始终保持整洁，PR 提交也更加清晰可控。
说到这里，不得不提几个工程实践中的常见陷阱。
第一个是数据持久化问题。很多人习惯把模型输出直接写在容器内部路径，结果容器一删，数据全丢。正确的做法是通过-v挂载外部存储卷，确保训练成果保存在主机上。同时结合.gitignore过滤这些输出路径，避免误提交大文件。
第二个是权限与路径混淆。在容器中运行git clean时，要注意当前用户是否有权限删除某些文件。特别是在多用户共享服务器环境下，建议始终以非 root 用户运行容器，并设置合理的文件所有权。
第三个是过度清理风险。有些人图省事直接写成脚本自动执行git clean -fxd，结果某天不小心在一个错误目录下运行，把未提交的重要代码删了。因此，强烈建议将清理操作封装成带确认提示的 shell 函数，或者集成进 Makefile 中作为受控任务。
例如：
clean: @git clean -n @read -p "Proceed with clean? [y/N] " && [[ $$REPLY =~ ^[Yy]$$ ]] || exit 1 git clean -fd这样每次执行make clean都会先预览再确认，安全性高得多。
最后回到根本目的：为什么我们要如此重视“清理”这件事？
因为在机器学习工程中，可复现性 = 环境一致性 + 代码纯净性 + 数据可控性。
- 镜像解决了环境一致性；
- Git 解决了代码版本管理；
- 而
git clean则是在这两者之间架起了一座桥梁——它帮助我们在每次实验后快速剥离“噪声”，让项目始终处于一个可交付、可审计的状态。
这不是简单的磁盘清理，而是一种工程纪律。
尤其是在 CI/CD 流水线中，自动化测试前往往会插入一步git clean -fdx，确保构建环境完全干净，不受缓存或临时文件影响。这种“轻量清理 + 重装环境”的范式，正是现代 MLOps 的核心思想之一。
所以，下次当你准备开始新一轮实验时，不妨先花一分钟做一次git status和git clean -n。看看哪些文件是你真正想保留的，哪些只是历史残留。你会发现，一个干净的工作区，不仅能提升效率，还能让你的思维更清晰。
毕竟，好的代码，从来不只是功能正确，更是结构清晰、易于维护。
