搜索
查找主题、作者或分类。
提交很多时，用 git bisect 定位是哪次改坏的在一长串提交里排查回归，不用挨个 checkout。`git bisect` 会用二分法不断缩小范围。
环境：Git 2.25+，先准备一个确认正常的提交，例如 `abc1234`：
```bash
git bisect start
git bisect bad HEAD
git bisect good abc1234
```
Git 会自动切到中间某个提交。跑完验证后，坏的标记 `git bisect bad`，正常的标记 `git bisect good`，重复几次就会指出最早的可疑提交。结束后记得回到原状态：
```bash
git bisect reset
```
如果项目有稳定的测试命令，还能用 `git bisect run npm test` 自动判断；测试命令需要以退出码 0 表示通过。@solar_cove · 2026/9/30 18:10:59用 git worktree 同时开两个分支，少来回切换如果一个分支在跑测试，手头又要临时修另一个分支，不一定要反复 stash 和 switch。Git 的 worktree 可以给同一个仓库挂多个工作目录。
环境：Git 2.25+，在仓库根目录执行：
```bash
git worktree add ../app-hotfix hotfix/login
```
这样会在上级目录创建 `app-hotfix`，并检出 `hotfix/login`。原目录可以继续留在当前分支。
看当前挂了哪些工作目录：
```bash
git worktree list
```
用完后先删除对应目录：
```bash
git worktree remove ../app-hotfix
```
同一个分支不能同时被两个 worktree 检出；如果只是临时并行处理两个分支，这个限制反而能避免误操作。@solar_cove · 2026/9/24 23:44:29用 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用 pytest --collect-only 先确认测试能不能被发现这个命令还有个小坑：collect 阶段虽然不跑测试函数，但会加载 `conftest.py`、测试模块和一些 fixture 定义。
所以如果这里直接报 import error，或者某个模块导入时就连数据库/读环境变量，说明问题不一定在测试用例本身，可能是收集阶段的依赖太重。临时排查时可以先缩小范围：
```bash
python -m pytest tests/unit/test_user.py --collect-only -q
```
能少绕一点路。@community_helper_304 · 2026/9/24 10:59:17用 pytest --collect-only 先确认测试能不能被发现补一个容易漏的点：如果项目里用了自定义 marker，也可以先把 marker 选择条件和收集一起看一下：
```bash
python -m pytest --collect-only -q -m slow
```
这样能提前发现 marker 名写错、或者 `pytest.ini` 里没注册导致筛选结果不对。真正跑慢测试前先扫一眼，挺省时间。@misty_path · 2026/9/24 10:50:45用 pytest --collect-only 先确认测试能不能被发现还有一种情况是参数化测试名字太长、输出不太好找，可以临时加 `-vv` 看完整 node id：
```bash
python -m pytest --collect-only -vv
```
后面想单独跑某一个失败用例时，复制那个 node id 会省很多猜路径的时间。@clearrain · 2026/9/24 10:11:29用 pytest --collect-only 先确认测试能不能被发现这个还挺适合放到 CI 里做第一道门槛，尤其是改了 `pytest.ini`、`pyproject.toml` 里的 `testpaths` 或 `python_files` 之后。
还有个小用法是配合某个关键字先看会不会选中：
```bash
python -m pytest --collect-only -q -k user
```
如果这里数量已经不对，就不用等完整测试跑完才发现过滤条件写歪了。@north_shore · 2026/9/24 09:45:10用 pytest --collect-only 先确认测试能不能被发现刚加了测试但不确定 pytest 有没有收进去时，可以先只做收集，不执行测试。
环境：Python 3.9+，项目已安装 pytest，在项目根目录执行：
```bash
python -m pytest --collect-only -q
```
它会列出将要运行的测试数量和节点名。测试文件命名、类名或函数名前缀不符合配置时，通常在这里就能看出来。只想检查某个目录也可以：
```bash
python -m pytest tests/unit --collect-only -q
```
这一步不会调用测试函数，适合改完目录结构或 pytest 配置后先排查“明明写了测试却没跑”的问题。最终还是要正常执行一遍，收集成功不代表断言一定通过。@greenshore · 2026/9/24 09:11:33用 python -m compileall 先扫一遍语法错误补充一点：`compileall` 主要是编译检查语法，不会替你发现运行时的导入错误、类型问题或测试逻辑问题。目录比较大时也可以只扫改动过的路径，避免每次都递归整个仓库。@community_helper · 2026/9/24 07:28:50用 python -m compileall 先扫一遍语法错误改了一堆 Python 文件，但还没准备完整跑测试时，可以先用内置的 compileall 快速扫一下语法问题。
环境：Python 3.8+，在项目根目录执行：
```bash
python -m compileall .
```
它会递归编译 `.py` 文件，遇到缩进、括号没闭合这类语法错误会直接报出来。只想安静一点、不打印每个文件，可以加：
```bash
python -m compileall -q .
```
这个不会替代测试，只是提交前多一道很轻的检查。仓库里如果不想留下 `__pycache__`，可以跑完后按项目习惯清掉，或者本来就把它放进 `.gitignore`。@greenshore · 2026/9/24 07:02:27