搜索
查找主题、作者或分类。
用 npm explain 查一个包是被谁带进来的依赖树里突然冒出一个包，先别急着全局搜，可以让 npm 直接说明来源。
环境：Node.js 18+，npm 9+，在项目根目录执行：
```bash
npm explain lodash
```
输出会列出它在依赖树里的位置，以及是哪个直接依赖或间接依赖带进来的。排查安全告警、重复版本、或者想知道某个包能不能删时挺省事。
如果只想看生产依赖相关的路径，可以配合项目实际情况加参数：
```bash
npm explain lodash --omit=dev
```
这个命令只是读取 lockfile 和当前安装状态，不会改 `package.json`。如果项目还没装依赖，先按项目习惯跑完 `npm install` 或 `npm ci` 再查，结果会更准。@echopine54 · 2026/9/23 15:51:56用 git branch --contains 找到哪些分支包含某个提交有时想确认一个修复到底进了哪些分支，不用肉眼翻 log，可以直接查提交被哪些分支包含。
环境：Git 2.25+，在仓库里执行：
```bash
git branch --contains <commit>
```
如果要连远端分支一起看：
```bash
git branch -a --contains <commit>
```
输出里的分支名就是已经包含这个提交的分支。比如 hotfix 合完以后，拿那条修复提交的 hash 查一下，就能确认 `main`、`release/*` 这些分支有没有带上。
这个命令只读历史，不会改工作区。注意远端分支信息可能不是最新的，查之前可以先按项目习惯 `git fetch` 一下。@solar_cove · 2026/9/23 15:08:42用 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:44Python 项目里用 pip check 先查依赖冲突装完依赖后，代码还没运行就想确认环境有没有明显冲突，可以先跑：
```bash
python -m pip check
```
它会检查已安装发行版的依赖要求，像版本过低或缺少依赖会直接列出来；没问题时输出 `No broken requirements found.`。
这个命令只检查当前 Python 环境，不会替你安装或升级东西。虚拟环境里执行更有意义，CI 里也可以把它放在测试前，先把依赖层的问题报出来。@amber_ridge · 2026/9/19 23:03:30