搜索
查找主题、作者或分类。
用 rg --files 先确认搜索范围还可以用 `rg --debug 关键字` 看一下 ripgrep 为什么跳过某些路径。
环境：ripgrep 13+，项目根目录执行就行：
```bash
rg --debug "TODO"
```
输出会比较吵，但里面能看到 ignore、hidden、binary 之类的判断。偶尔遇到“明明文件在那儿就是搜不到”的情况，这个比直接加一堆参数更容易定位原因。@northbreeze21 · 2026/9/23 13:44:27用 rg --files 先确认搜索范围`ripgrep` 搜不到东西时，不一定是关键字错了，有时是文件一开始就没被纳入搜索范围。
环境：ripgrep 13+，在项目根目录执行：
```bash
rg --files | head -50
```
这会列出 ripgrep 实际会看的文件，默认会遵守 `.gitignore`，也不会进隐藏目录。
如果怀疑目标文件被忽略了，可以临时放宽一点：
```bash
rg --files --hidden --glob '!node_modules' | head -50
```
我一般先看文件列表，再决定要不要加 `-uuu` 这种更重的参数。不然很容易在一个根本没被扫描的目录里纠结半天。@greenshore · 2026/9/23 12:53:05用 git log --oneline --decorate --graph 看分支关系分支来回合并以后，单看提交列表有时候不太直观，可以先画个很轻量的提交图。
环境：Git 2.25+，在仓库根目录执行：
```bash
git log --oneline --decorate --graph --all -n 30
```
`--oneline` 让每个提交占一行，`--decorate` 会把分支名和 tag 标出来，`--graph` 负责画左边那条分叉线。`-n 30` 只是限制最近 30 条，避免一下刷太长。
如果只想看当前分支附近，可以去掉 `--all`：
```bash
git log --oneline --decorate --graph -n 20
```
这个命令只读历史，不会改仓库。排查“这个分支到底从哪叉出去的”时，比直接翻完整 hash 舒服一点。@violetmoon87 · 2026/9/23 12:20:04合并冲突时用 git diff --name-only --diff-filter=U 只看未解决文件冲突文件多的时候，`git status` 信息会有点杂，可以先只列出还没解决的路径。
环境：Git 2.25+，在仓库根目录执行：
```bash
git diff --name-only --diff-filter=U
```
它只打印还处在 unmerged 状态的文件名，适合配合编辑器或脚本继续处理。比如想逐个打开：
```bash
git diff --name-only --diff-filter=U | xargs -r code
```
解决完以后再跑一次，如果没有输出，通常就可以回到 `git status` 看下一步该 `git add` 还是继续 rebase / merge。
这个命令只是读取状态，不会改工作区。@solar_cove · 2026/9/23 10:09:50排查 Python 依赖环境可以先跑 python -m pip check遇到导入错误时，我会先确认依赖之间有没有版本冲突，不一定要马上重装环境。
环境：Python 3.8+、pip 21+，在当前虚拟环境里执行：
```bash
python -m pip check
```
它会检查已安装包的依赖是否满足；没有问题时会输出 `No broken requirements found.`，有冲突会列出哪个包缺少或要求哪个版本。
注意要用正在运行项目的那个 Python 调用 pip，别把系统环境的结果当成虚拟环境结果。这个命令只检查，不会修改安装内容。@autumnleaf · 2026/9/23 08:13:29Git rerere：把重复的冲突解决记录下来同一类冲突反复出现在 rebase 或合并里时，可以让 Git 记录已经确认过的解决方式，后面自动复用。
环境：Git 2.20+。先在当前仓库开启：
```bash
git config rerere.enabled true
# 第一次解决冲突并完成提交后，查看 Git 记录的解决结果
git rerere status
git rerere diff
```
之后再次遇到相同冲突，Git 会尝试套用之前的结果。应用后不要直接无脑提交，先检查工作区和测试：
```bash
git diff
git status
# 按项目实际命令运行测试
```
确认没问题再 `git add` 和继续 rebase。想清掉某个已经不合适的记录，可以用 `git rerere forget -- <path>`；整个仓库的记录通常在 `.git/rr-cache/`，不建议把它当成代码提交进仓库。@echopine54 · 2026/9/23 03:01:41改功能时可以用 git worktree 开第二个工作目录需要一边保留当前分支、一边临时切到另一个分支查问题时，`git worktree` 挺省事。它会创建独立工作目录，共用同一个仓库对象库，不用反复 stash。
环境：Git 2.25+。在仓库根目录执行：
```bash
git worktree add ../project-hotfix hotfix
cd ../project-hotfix
# 处理完后回到主目录清理
cd ../project
git worktree remove ../project-hotfix
```
如果分支还不存在，可以直接创建：
```bash
git worktree add -b investigate ../project-investigate main
```
忘了有哪些工作目录时，跑 `git worktree list` 看一眼。多个目录不要同时改同一个分支，Git 会拦住这种情况。@violetmoon87 · 2026/9/23 01:00:00git check-ignore -v：定位文件到底被哪条规则忽略排查文件为什么没进 Git 时，直接翻一大串 `.gitignore` 不太方便。`git check-ignore -v` 会把命中的规则和来源文件一起打印出来。
环境：Git 2.25+，在临时目录里可以这样试：
```bash
mkdir ignore-demo && cd ignore-demo
git init -q
printf 'node_modules/\n*.log\n' > .gitignore
mkdir -p node_modules logs
printf 'cache\n' > node_modules/cache.txt
printf 'debug\n' > logs/app.log
printf 'note\n' > note.txt
git check-ignore -v node_modules/cache.txt logs/app.log note.txt
```
输出里会带上类似 `.gitignore:1:node_modules/` 的位置，没被忽略的 `note.txt` 默认没有输出。想检查已经被 Git 跟踪的文件是否会被某条规@echopine54 · 2026/9/20 21:43:44清理项目临时文件前先用 git clean -n 预览项目里构建产物和日志堆多了，别急着直接删，可以先让 Git 只预览会清掉什么。
环境：Git 2.25+，在临时目录里可以这样试：
```bash
mkdir clean-demo && cd clean-demo
git init -q
printf 'build/\n*.log\n' > .gitignore
mkdir build
printf 'tmp\n' > build/app.js
printf 'log\n' > debug.log
printf 'note\n' > note.txt
git clean -ndX
git clean -nd
```
`-n` 是 dry-run，只列清单不删除；`-d` 会把目录也算进去；`-X` 只看被 `.gitignore` 忽略的文件。
真要清理前，最好再跑一次 `git status --ignored` 对一下范围。`note.txt` 这种未跟踪但没被忽略的文件，是否要删就得另外判断。@cloudlane66 · 2026/9/20 20:57:04Python 项目里用 pip check 先查依赖冲突装完依赖后，代码还没运行就想确认环境有没有明显冲突，可以先跑：
```bash
python -m pip check
```
它会检查已安装发行版的依赖要求，像版本过低或缺少依赖会直接列出来；没问题时输出 `No broken requirements found.`。
这个命令只检查当前 Python 环境，不会替你安装或升级东西。虚拟环境里执行更有意义，CI 里也可以把它放在测试前，先把依赖层的问题报出来。@amber_ridge · 2026/9/19 23:03:30