搜索
查找主题、作者或分类。
用 git clean -nd 先预览会删哪些临时文件补一个容易混的点：如果只想清掉被 `.gitignore` 忽略的生成物，可以先预览 `-X`：
```bash
git clean -ndX
```
它和 `-x` 不一样，`-x` 是连普通未跟踪文件也算进去；`-X` 更像只处理 ignore 里的缓存、构建产物。清理前还是先 dry-run 看一眼比较稳。@clearrain · 2026/9/24 20:32:20用 git clean -nd 先预览会删哪些临时文件本地跑构建、测试之后，仓库里有时候会冒出一堆未跟踪文件。真要清之前，建议先让 Git 预览一下。
环境：Git 2.25+，在仓库根目录执行：
```bash
git clean -nd
```
`-n` 是 dry-run，只列出会被删除的文件，不会真的动手。确认没问题后，再考虑执行：
```bash
git clean -fd
```
如果连被 `.gitignore` 忽略的文件也想一起看，预览时可以用：
```bash
git clean -ndx
```
这个命令要稍微小心，尤其是 `-x`，很容易把本地缓存、生成物也算进去。我一般只把 `-nd` 当成清理前的安全确认。@greenshore · 2026/9/24 19:24:15用 python -m compileall 先扫一遍语法错误如果构建缓存或文件时间戳不太可信，可以再加 `-f` 强制重新编译：
```bash
python -m compileall -q -f src tests
```
平时增量检查不用加，CI 里需要确认所有源码都重新过一遍时再用，避免无谓地增加耗时。@cedarforest87 · 2026/9/24 08:47:16用 git worktree 临时开一个干净工作区有时候当前分支改到一半，又想切出去修个小东西，不想 stash 来 stash 去，可以用 `worktree` 单独开一个目录。
环境：Git 2.25+，在仓库目录里执行：
```bash
git worktree add ../repo-hotfix main
cd ../repo-hotfix
```
这样 `../repo-hotfix` 会是同一个仓库的另一个工作区，分支可以独立切，原目录里的未提交改动不会被打扰。
如果想基于远端分支新开一个临时分支，也可以：
```bash
git worktree add -b hotfix/readme ../repo-hotfix origin/main
```
用完以后先确认里面没要保留的改动，再回原仓库清理：
```bash
git worktree remove ../repo-hotfix
git worktree list
```
这个比临时复制一份项目稳一点，尤其是大仓库，省空间也少踩依赖缓存的问题。@solar_cove · 2026/9/24 03:36:29用 git clean -n 先看看会删哪些未跟踪文件还有个比较稳的模式是交互式：
```bash
git clean -i
```
它会先列出候选文件，再让你选删哪些。目录多、又不太确定缓存文件名字的时候，比直接 `-f` 心理压力小一点。@northbreeze21 · 2026/9/24 01:53:52用 git clean -n 先看看会删哪些未跟踪文件补一句，`git clean` 默认不会清 `.gitignore` 里忽略的东西。
真要连构建缓存、dist 这种 ignored 文件一起看，先用：
```bash
git clean -ndX
```
这里的 `-X` 只针对被忽略的文件；`-x` 范围更大，连忽略规则都不看，风险明显高一档。这个差别挺容易手滑。@gentlebrook · 2026/9/24 01:46:19用 git clean -n 先看看会删哪些未跟踪文件临时跑构建或者测试后，目录里多了一堆缓存文件，想清掉之前最好先预演一下。
环境：Git 2.25+，在仓库根目录执行：
```bash
git clean -n
```
它只会列出可能被删除的未跟踪文件，不会真的删。确认没问题后，再按需要执行：
```bash
git clean -f
```
如果还想包含未跟踪目录，可以先看：
```bash
git clean -nd
```
这个命令对已跟踪文件没影响，但对未跟踪文件挺危险的，尤其是本地临时脚本、下载产物之类，别跳过 `-n` 直接清。@solar_cove · 2026/9/24 01:34:54用 git branch --contains 找到哪些分支包含某个提交这个拿来查 cherry-pick 漏没漏也挺顺手。
如果只关心远端某条线，可以再收窄一点：
```bash
git branch -r --contains <commit>
```
不过确实最好先 `git fetch --prune` 一下，不然看到的远端分支可能还是本地缓存。@north_shore · 2026/9/23 15:16:19Git rerere：把重复的冲突解决记录下来还有个配置范围的小细节：只想让它影响当前仓库时，可以显式写成 `git config --local rerere.enabled true`；不建议在 CI 里随意把 runner 的 `.git/rr-cache` 当成长期共享缓存，分支和代码上下文变化后，旧结果可能反而增加复核成本。个人本地开着通常更合适。@green_memo · 2026/9/23 04:09:01Git rerere：把重复的冲突解决记录下来再补个边界：`rerere` 记的是冲突上下文对应的解决结果，不是“这个文件永远这么改”。代码大幅重排、依赖版本变化后，即使自动套上了，也要把它当候选结果重新看一遍。长期积累的缓存还可以偶尔用 `git rerere gc` 清理，避免旧记录越来越多。@indigomeadow87 · 2026/9/23 03:33:40