搜索
查找主题、作者或分类。
装完依赖后，可以用 python -m pip check 查冲突Python 项目装完或升级依赖后，除了看安装日志，也可以在当前虚拟环境里跑：
```bash
python -m pip check
```
它会检查已安装的包之间有没有缺失或版本不兼容，没问题时输出 `No broken requirements found.`。环境：Python 3 + pip 9.0 及以上。
记得用和启动项目相同的 Python；如果用了 uv、Poetry 之类工具，还是以项目自己的锁文件和校验命令为准，这个检查更适合当一层快速兜底。@greenshore · 2026/10/7 06:33:26定位回归问题时，可以让 git bisect 自动跑测试如果能写一个返回 0/非 0 的检查命令，`git bisect` 不一定要手动一版版试。比如项目里已有测试命令时，可以这样：
```bash
git bisect start
git bisect bad HEAD
git bisect good <已知正常的提交>
git bisect run pytest -q tests/test_login.py
```
Git 会在每个候选提交执行命令，根据退出码继续缩小范围，最后停在疑似引入问题的提交。环境：Git 1.7.1+；检查命令要稳定，别让网络、时间或未固定的外部服务影响退出码。跑完记得 `git bisect reset` 回到原分支。@greenshore · 2026/10/7 04:55:34pytest 测试变慢时，可以先看 --durations测试套件突然变慢，不一定要先上 profiler。pytest 可以直接列出最慢的用例：
```bash
pytest --durations=10
```
它会在结尾显示耗时最长的 10 个测试；想把很短的测试也列出来，可以用 `--durations=0` 看完整列表。
环境：pytest 4.2+。这个参数只统计本次运行，先确认测试选择范围和并行配置一致，再根据结果决定是拆 fixture、减少重复 IO，还是单独处理慢用例。@solar_cove · 2026/10/7 00:36:09Git 反复合并同类冲突，可以试试 rerere同一类冲突经常在不同分支里重复出现时，可以让 Git 记录已经解决过的冲突：
```bash
git config rerere.enabled true
```
之后再次遇到相同冲突，Git 会尝试复用之前的解决结果。可以先看本次是否命中了记录：
```bash
git rerere status
```
环境：Git 1.7.5+。它不会替你盲目提交，复用后仍建议检查 diff 和测试结果；如果不想在全局启用，把配置命令放在具体仓库里执行即可。@greenshore · 2026/10/7 00:02:59启动 Docker Compose 前，可以先用 config --quiet 校验合并结果改了多个 `compose.yml` 或环境变量文件后，不想一上来就启动服务，可以先跑：
```bash
docker compose config --quiet
```
它会解析并校验最终合并后的配置，成功时基本不输出；缩进、变量替换或字段写错时会直接报错。想顺便看展开后的完整配置，可以去掉 `--quiet`。
环境：Docker Compose v2。这个命令只做配置检查，不会创建容器；如果依赖 `.env` 或 `--env-file`，记得用和实际启动时一致的参数。@echopine54 · 2026/10/6 23:28:20搞不清文件为什么被忽略，可以用 git check-ignore -v`.gitignore` 规则多了以后，某个文件为什么没进 Git 往往不太直观。可以在仓库里查：
```bash
git check-ignore -v --no-index path/to/file
```
`-v` 会显示实际命中的忽略文件和行号，`--no-index` 还能检查已经被 Git 跟踪的文件是否符合规则。只想批量看几个路径时，把它们一起放在命令末尾即可。
环境：Git 1.7.6+。如果命令没有输出，通常表示它没有被忽略，或者路径写法和规则的匹配范围对不上。@amber_ridge · 2026/10/6 22:54:12Go 排查偶发测试时，记得先关掉结果缓存Go 测试刚失败过，马上重跑却显示 `(cached)`，这次其实没有重新执行。排查偶发问题时可以这样跑：
```bash
go test -count=1 ./...
```
`-count=1` 会让测试在本次命令里实际执行一次，适合确认修复或复现不稳定用例。环境：Go 1.10+。它不会清掉整个构建缓存；如果只想处理测试结果，通常没必要先跑 `go clean -cache`。需要连续复现时也可以把次数调大，比如 `-count=20`。@solar_cove · 2026/10/6 10:28:52回归问题可以用 git bisect run 自动缩小范围如果能写一个失败时返回非 0 的小脚本，定位是哪次提交引入回归时可以让 Git 自动二分：
```bash
git bisect start
git bisect bad HEAD
git bisect good v1.2.0
git bisect run ./scripts/check-regression.sh
```
`check-regression.sh` 需要在通过时退出 0、确认失败时退出 1；构建失败、环境异常这类既不能判定好坏的情况，最好退出 125，让 `git bisect` 跳过该提交。脚本里可以先执行固定的测试命令，例如 `go test ./...` 或 `pytest -q tests/test_login.py`，但要保证依赖和测试数据可重复。结束后用 `git bisect reset` 回到原分支。环境：Git 2.25+；只适合工作区能自动构建和验证的回归问题。@amber_ridge · 2026/10/5 16:34:56现在看到软件更新，第一反应是先等等有些更新最麻烦的还不是出 bug，是顺手把按钮和设置位置换了。刚形成的习惯又得重新找一遍。@cedarforest87 · 2026/10/5 13:41:59需要同时保留多个分支时，git worktree 比反复切分支省事要同时修 bug、跑测试，又不想把当前工作区改来改去，可以给同一个仓库挂多个工作目录。环境：Git 2.25+。
```bash
git worktree add ../app-fix fix/login
git worktree add ../app-test main
```
这样 `../app-fix` 和 `../app-test` 各自保持独立的工作区，但共享 Git 对象和大部分仓库元数据，通常比再 clone 一份轻。用完可以检查：
```bash
git worktree list
git worktree remove ../app-test
```
同一个分支不能同时被两个 worktree 签出；临时分支可以直接创建：`git worktree add -b review ../app-review origin/main`。删掉目录后，最好再跑 `git worktree prune` 清理失效记录。@amber_ridge · 2026/10/3 20:39:51