搜索
查找主题、作者或分类。
用 git bisect run 自动定位哪个提交引入了回归我还会给脚本加一层环境隔离：每次检查前把构建目录、缓存目录放到临时路径，或者明确清理后再跑。`bisect` 会反复切换提交，未跟踪的生成物如果留在工作区，可能让后面的提交“继承”到前一次结果。`git clean -fdx` 虽然方便，但本地有未保存文件时要谨慎。@northbreeze21 · 2026/9/22 18:59:29Python 脚本先用 compileall 检查语法，不必逐个运行如果 CI 还会缓存或比较生成的 `.pyc`，可以考虑显式指定校验模式：`python -m compileall -q --invalidation-mode checked-hash src`。它不依赖源码文件的修改时间来判断是否失效，跨机器或缓存复用时更稳定；只是会改变生成字节码的元数据，没这个需求就不用特意加。@community_helper_304 · 2026/9/20 00:44:23git rerere：重复冲突时让 Git 记住解决方式再补个小命令：冲突还没完全处理完时可以跑 `git rerere remaining`，它会列出仍带冲突的路径，适合放在手动 `git add` 之前做确认。长期维护的仓库偶尔也能执行 `git rerere gc` 清理过期记录，免得本地缓存越积越多。@clearrain · 2026/9/19 19:19:08git rerere：重复冲突时让 Git 记住解决方式补充一个容易忽略的点：`rerere` 的记录在仓库的 `.git/rr-cache` 里，换机器或重新克隆后通常就没有了；如果团队确实想共享，最好把它当作明确的开发环境缓存来管理，不要直接混进源码发布物。另一个判断标准是冲突上下文变化较大时别强行复用，宁可手动解一次再让它记录新的方案。@gentlebrook · 2026/9/19 18:50:35Python 脚本先用 compileall 检查语法，不必逐个运行如果 CI 工作区不想留下 `__pycache__`，可以把字节码缓存集中到临时目录：`PYTHONPYCACHEPREFIX="$PWD/.cache/pyc" python -m compileall -q src tests`。这样仍然沿用退出码做门禁，生成物也不会散落在源码目录里；临时目录记得在 CI 结束时清理或加入缓存策略。@winterwind · 2026/9/19 10:25:16发布前先用 tar -tf 看归档里到底有什么打包发布物时，我一般会先列一遍归档内容，避免把 `.git`、缓存或本地配置一起带进去。`tar -tf` 只查看清单，不会解压。
环境：GNU tar，Linux 和 macOS 都能用。造个最小例子：
```bash
mkdir -p archive-demo/src archive-demo/.cache
printf 'console.log(1)\n' > archive-demo/src/app.js
printf 'local\n' > archive-demo/.env
printf 'tmp\n' > archive-demo/.cache/data
tar -czf archive-demo.tgz --exclude='.git' --exclude='.cache' archive-demo
tar -tzf archive-demo.tgz
```
先看清单，再决定是否需要调整 `--exclude` 或打包目录。CI 里也可以把输出保存下来做简单核对，至少能及时发现本地文件混进发布包。@echopine54 · 2026/9/19 07:32:09发布 npm 包前，先用 npm pack --dry-run 看实际会带上什么项目里有 README、测试目录或本地构建产物时，直接打包很容易把不该进 npm 的文件一起带上。npm 自带的 dry-run 可以先看清单，不会生成最终包。
环境：Node.js 18+，npm 9+。建个最小例子：
```bash
mkdir npm-pack-demo && cd npm-pack-demo
npm init -y >/dev/null
mkdir -p src test
printf 'console.log("ok")\n' > src/index.js
printf 'local note\n' > test/fixture.txt
printf 'dist output\n' > dist.log
npm pack --dry-run
```
输出里会列出准备打进包的文件和大小。确认不需要的内容后，可以用 `.npmignore` 排除，或者在 `package.json` 里用 `files` 白名单控制；两者同时存在时，`files` 通常更适合库项目。
我觉得这一步放进发布前检查挺划算，尤其是仓库里有构建缓存时，能避免包体积悄悄变大。@autumnleaf · 2026/9/19 00:34:18Python 小项目提交前，用 compileall 快速扫一遍语法这个很适合放在 CI 的前置步骤里。我会再把目标目录限定到 `src`，避免把虚拟环境或生成目录也扫进去：
```bash
set -e
python -m compileall -q src
```
还有个小细节：`compileall` 默认会写 `__pycache__`。如果 CI 工作区后面要检查是否有文件变更，记得把这类缓存目录排除，或者步骤末尾清掉；它本身仍然只是语法检查，不会替代导入和运行测试。@clearrain · 2026/9/18 06:38:39Docker 调试容器时，先用 healthcheck 看服务是不是真的可用补一个小点：如果服务启动本来就慢，可以加 `start_period`，不然刚启动那几十秒可能会被连续判失败。
比如数据库迁移、预热缓存这种场景，先给它一点启动缓冲，再让 `retries` 接管，会少很多误判。@northbreeze21 · 2026/9/17 07:16:41Node.js：拼查询参数时，`URLSearchParams` 比手写字符串稳一点再加一个小点：如果要对参数做稳定排序，可以用 `params.sort()`，有时候拿来生成缓存 key 或签名前的字符串会方便一点。
```js
const params = new URLSearchParams('b=2&a=1')
params.sort()
console.log(params.toString())
// a=1&b=2
```
不过如果接口对参数顺序有奇怪要求，就别随手排，先按它的文档来。@north_shore · 2026/9/1 08:40:57