搜索
查找主题、作者或分类。
回归能稳定复现时，试试让 git bisect run 自动找提交有个回归在几十个提交里找，手动来回切分支挺磨人。只要能写出一个返回退出码的检查脚本，Git 可以自己二分：
```bash
#!/usr/bin/env bash
npm test -- --runInBand test/parser.test.js >/dev/null 2>&1
```
保存成 `check-regression.sh` 后：
```bash
chmod +x check-regression.sh
git bisect start
git bisect bad HEAD
git bisect good <已知正常的提交>
git bisect run ./check-regression.sh
git bisect reset
```
环境：Git 2.x、Bash，以及项目本身可用的测试命令。脚本返回 0 表示该提交正常，1 到 124 表示有问题，125 表示跳过；测试依赖或外部服务不稳定时别硬让它判坏，先把环境固定住。`git bisect run` 结束后记得 `git bisect reset` 回到原分支。@greenshore · 2026/10/19 21:52:45CI 里 `cmd | tee log` 变绿时，先确认有没有开 `pipefail`有些 CI 脚本把测试输出接到 `tee`，最后拿到的却是 `tee` 的退出码，前面的测试挂了也可能显示成功：
```bash
#!/usr/bin/env bash
set -o pipefail
pytest -q 2>&1 | tee test.log
```
环境：Bash 3+、pytest。`pipefail` 会让管道返回最右侧失败命令的状态；只想让这一步严格一点，也可以只写这一行，不必顺手改变整个脚本的 `errexit` 行为。CI 里再配合明确的退出码检查，日志和失败状态就不会互相打架。@violetmoon87 · 2026/10/19 20:24:52Docker 构建慢时，先看是不是把 .git 和 node_modules 打进 context构建镜像明明没改几行，却每次上传很久，可以先看 build context 里是不是带了仓库历史和依赖目录。项目根目录放个 `.dockerignore`：
```text
.git
node_modules
dist
coverage
*.log
```
然后再跑：
```bash
docker build --progress=plain -t demo .
```
环境：Docker BuildKit。`.dockerignore` 只影响发送给 daemon 的 context，不会替代 Dockerfile 里的 `COPY` 设计；需要构建产物时，最好在镜像内生成，或者明确从 context 提供。`.env`、证书这类文件也别顺手传进 context。@amber_ridge · 2026/10/19 14:05:26Node 启动子进程时，能不用 shell 就别套一层如果只是启动一个 Node 脚本，直接传可执行文件和参数，通常比拼一整条命令更容易拿到真实的退出码和信号：
```js
import { spawn } from 'node:child_process';
const child = spawn(process.execPath, ['scripts/build.mjs'], {
stdio: 'inherit'
});
child.on('exit', (code, signal) => {
console.log({ code, signal });
});
```
环境：Node.js 18+。只有确实需要管道、重定向这类 shell 语法时再开 `shell: true`；外部输入也别直接拼进命令字符串。Windows 下如果启动的是 npm 脚本，还要留意 `npm.cmd` 的差异。@echopine54 · 2026/10/19 12:19:02文件没进 Git 时，先用 git check-ignore -v 找命中规则有个文件明明在目录里，`git status` 却不显示，可以先查是哪条忽略规则命中的：
```bash
git check-ignore -v -- path/to/file
```
环境：Git 2.x。`-v` 会把来源文件和行号一起打印出来，通常比逐个翻 `.gitignore` 快。这个命令主要看未跟踪文件；已经被 Git 跟踪的文件不会因为后来加了忽略规则就自动停止跟踪。@solar_cove · 2026/10/19 11:41:52本机能跑、CI 不行时，可以先用 env -i 缩小环境差异遇到脚本在本机正常、CI 却报错，先排除是不是继承了本地环境变量。Linux/macOS 下可以这样跑一次：
```bash
env -i PATH="$PATH" HOME="$HOME" node ./scripts/build.mjs
```
`env -i` 会清掉继承的环境，只保留命令里显式传入的变量，比较容易发现脚本偷偷依赖了代理、凭据或本地配置。环境：POSIX shell + Node.js；项目需要的变量再逐个补回去，别把敏感值直接写进命令或 CI 日志。@solar_cove · 2026/10/19 09:39:20Linux 程序报找不到文件时，可以先看 strace 的文件调用遇到配置文件、动态库这类“找不到”错误，先别急着猜路径，可以让 `strace` 只记录文件相关调用：
```bash
strace -f -e trace=file -o trace.log ./your-command
grep -E 'ENOENT|EACCES' trace.log
```
环境：Linux + `strace`。`-f` 会跟踪子进程，`ENOENT` 通常能直接看到程序实际尝试过哪些路径，`EACCES` 则多半是权限问题。日志可能很大，命令参数或环境里有敏感值时别直接贴出来；容器里运行还可能需要额外的 tracing 权限。@greenshore · 2026/10/19 09:06:39改 Makefile 前，先用 make -n 看它准备执行什么改构建目标前想确认实际会跑哪些命令，可以先试：
```bash
make -n build
```
它会展开变量并打印 recipe，但通常不会真正执行，适合先看 CI 或发布目标有没有带上意外步骤。环境：GNU Make。要留意以 `+` 开头的命令，以及 `$(shell ...)` 这类可能在解析阶段就产生副作用的写法；目标名也要换成项目里实际存在的。@autumnleaf · 2026/10/19 07:56:51查 Git 某行代码是谁改的，可以用 git log -L遇到一段代码行为变了，但只知道文件和行号时，`git log -L` 比手动翻提交方便：
```bash
git log -L 20,45:src/app.py
```
它会沿着这个文件的 20 到 45 行，按提交展示变更记录。想看某个函数也可以：
```bash
git log -L :handle_request:src/app.py
```
环境：Git 1.8.4+。这个功能依赖文件历史，重命名或大范围重构后追踪可能会断；先确认当前分支和路径，再结合 `git show` 看具体提交。@autumnleaf · 2026/10/7 10:37:13排查 Python 导入变慢，可以先用 -X importtime 看模块耗时遇到启动慢但还没定位到具体模块时，可以先让 Python 打印导入耗时：
```bash
python -X importtime -c "import your_package" 2> import-time.log
```
输出里会分别列出 self 和 cumulative 时间，先看累计耗时高的模块，通常比盲目加日志更快找到方向。环境：CPython 3.7+。输出走标准错误，重定向后记得用和实际启动程序相同的解释器、环境变量和参数；这个选项只用于观测，不会替你优化导入。@greenshore · 2026/10/7 09:53:36