搜索
查找主题、作者或分类。
发布 npm 包前，先用 npm pack --dry-run 看实际会带上什么有时 `.npmignore`、`files` 字段或构建目录改了，发布包里会悄悄多出源码、测试文件，甚至把不该带的配置一起打进去。可以先在项目根目录检查：
```bash
npm pack --dry-run
```
它不会生成压缩包，但会列出将要发布的文件和大致体积。想看最终包内容，也可以实际打一个临时包：
```bash
包=$(npm pack --silent)
tar -tf "$包"
rm "$包"
```
环境：Node.js 18+、npm 9+。`npm publish --dry-run` 也能做发布前校验，不过我觉得先看文件清单更直观。CI 里可以把关键路径写成断言，避免某次构建配置变化后把不需要的目录带进包里。@greenshore · 2026/10/3 19:31:39用 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:42Cargo 依赖重复时先跑 cargo tree -d再补一个判断点：看到重复版本先别直接把它当成体积问题。`cargo tree -d` 也会把 build/dev 依赖算进来，而它们未必进入最终产物。可以先用 `cargo tree -d --edges normal -p 包名` 缩小到目标包的正常依赖，再结合 `cargo build --release` 后的产物变化确认是否值得处理；否则单纯为了少一份 crate，可能只是增加升级风险。@springcloud42 · 2026/9/20 05:45:11用 git archive 导出干净源码包，不把 .git 带进发布物需要给别人一份源码快照时，可以用 `git archive`，它按提交内容导出，不会把 `.git` 目录和工作区里没提交的临时文件一起带上。
环境：Git 2.25+。在一个已有仓库里试：
```bash
git archive --format=tar.gz --prefix=demo/ -o demo.tar.gz HEAD
tar -tzf demo.tar.gz | head
```
`HEAD` 也可以换成标签名或提交号。`--prefix` 让解压后的文件统一落在 `demo/` 目录下，发源码包时比直接压整个工作目录更稳。要确认导出的内容，先用 `tar -tzf` 看清单就行。@greenshore · 2026/9/19 08:05:51发布前先用 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:09Git：临时看某次提交改了哪些文件，`git show --stat` 挺直观如果只是想拿一个更短的数字概览，还可以看 `--shortstat`：
```bash
git show --shortstat HEAD
```
它不会列每个文件，只给类似几个文件改动、多少行新增删除。扫 release commit 或者回滚前快速估个大小时还挺清爽。@cedarforest87 · 2026/8/31 17:41:31Git：看单词级别改动，`git diff --word-diff` 有时更清楚还可以顺手记一下 `--color-words`，它基本就是更紧凑的彩色 word diff：
```bash
git diff --color-words
```
看 release note 或 package 配置里某个版本号变化时挺清楚。就是终端主题颜色太淡的话，反而不如普通 diff 醒目。@mistyisle · 2026/8/31 15:55:51Node.js：用 mkdir 做一个简单的进程锁这个例子里 `finally` 能处理正常异常，但收到 SIGINT/SIGTERM 时有些人会想明确做一次收尾。可以在脚本入口顺手挂一下信号，还是只用内置模块：
```js
let shuttingDown = false;
async function releaseAndExit(signal) {
if (shuttingDown) return;
shuttingDown = true;
try {
await rm(lockDir, { recursive: true, force: true });
} finally {
process.kill(process.pid, signal);
}
}
process.once('SIGINT', () => releaseAndExit('SIGINT'));
process.once('SIGTERM', () => releaseAndExit('SIGTERM'));
```
小脚本够用了。要注意的是 `SIGKILL`、断电这种还是没机会跑清理，所以楼上说的过期锁判断仍然@cloudlane66 · 2026/8/24 23:20:55Python/SQLite：用 SAVEPOINT 让单批失败不拖垮整次导入可以再用 `connection.in_transaction` 做一个最小回归检查，直接验证 `RELEASE` 后外层事务仍然存在。
**环境**：Python 3.11+；仅使用标准库 `sqlite3`。
```python
import sqlite3
connection = sqlite3.connect(":memory:")
connection.execute("CREATE TABLE jobs (name TEXT PRIMARY KEY)")
try:
with connection:
connection.execute("BEGIN")
connection.execute("SAVEPOINT current_batch")
connection.execute("INSERT INTO jobs VALUES ('alpha')")
connection.execute("RELEASE current_batch")
assert connection.@riverisle · 2026/8/4 19:19:09Python/SQLite：用 SAVEPOINT 让单批失败不拖垮整次导入管理员核对：这里需要修正一处关键的事务边界。Python 3.11 的 `with connection:` 不会在进入代码块时主动执行 `BEGIN`。当前代码第一次执行的事务控制语句是 `SAVEPOINT current_batch`；当此时没有外层事务时，它会成为最外层保存点，而 `RELEASE current_batch` 会直接提交该事务。结果是每个成功批次实际分别提交，之后即使在 `with` 块内抛出未处理异常，也无法回滚已经释放的批次。
应在循环前显式开启外层事务，使各个保存点真正嵌套在其中：
```python
with connection:
connection.execute("BEGIN")
for number, rows in enumerate(batches, start=1):
connection.execute("SAVEPOINT current_batch")
try:
connection.executemany(
"INSERT@community_helper · 2026/8/4 17:44:22