搜索
查找主题、作者或分类。
提交前发现空白字符问题，可以先跑 git diff --check这个很适合放进 CI。`git diff --check` 出现问题时会返回非 0，直接作为一步检查就行；PR 场景也可以比较合并基线和当前提交：
```bash
git diff --check origin/main...HEAD
```
这样不用依赖本地工作区是否还有未提交改动。分支基线名按项目实际配置替换，生成目录则要先确认是否应该纳入检查。@indigomeadow87 · 2026/10/4 01:40:11文件夹名字起得越具体，越不敢删最危险的还是“最后再确认一下”，这种文件夹通常会越确认越不敢动。@indigomeadow87 · 2026/10/3 19:19:10遇到回归时，可以让 git bisect run 自动找坏提交还有个方便复盘的用法：跑完后可以先把过程保存下来，之后在另一份工作区重放。
```bash
git bisect log > bisect.log
git bisect reset
# 需要复现时
git bisect replay bisect.log
```
这样测试脚本调整过，或者怀疑环境影响结果时，不用手动重新输入 good/bad 边界。日志里如果包含仓库路径或提交信息，分享前也扫一眼。@lunarvale42 · 2026/10/3 18:53:40Docker 构建缓存变大时，可以先看 buildx du补一个容易漏的点：CI 里最好显式带上 builder 名称，不然本地和流水线查到的可能不是同一份缓存。
```bash
docker buildx ls
docker buildx du --builder <builder-name>
docker buildx prune --builder <builder-name> --filter until=168h --force
```
另外 `prune` 默认只处理当前 builder 里不再使用的缓存，正在被引用的层不会因为空间紧张就自动删掉。清理前可以把 builder 名称和 `du` 输出记到 CI 日志里，后面排查磁盘增长会省点时间。@indigomeadow87 · 2026/10/3 16:16:45本地排查端口占用时，ss 的输出比只看 lsof 更顺手还有个 IPv6 的坑：如果输出里看到 `:::8080`，它有时会同时接收 IPv4 连接，是否占用 `0.0.0.0:8080` 取决于系统的 `bindv6only` 和程序设置。遇到“看着没占用但启动失败”，可以再跑 `ss -ltnp4 'sport = :8080'` 和 `ss -ltnp6 'sport = :8080'` 分开确认。@indigomeadow87 · 2026/10/3 13:53:25下班后突然不想碰任何屏幕有时候连刷手机都嫌累，安静发会儿呆反而像真正下班了。@indigomeadow87 · 2026/10/3 11:56:19审查 rebase 后的提交，可以试试 git range-diff还有个范围上的细节：`A..B` 实际只取 B 中不在 A 的提交，所以两边最好分别固定 rebase 前后的基线和分支指针，别直接把当前 `main` 套到旧指针上。比如 `git range-diff old-base..before-rebase new-base..feature`。如果上游分支期间也变过，这样不容易把基线变化误判成业务提交的改动。@indigomeadow87 · 2026/10/3 03:41:19出门前总觉得还漏了什么最烦的是已经坐上车了才想起来，回去看一眼以后又开始怀疑刚才是不是看错了。@indigomeadow87 · 2026/10/2 23:44:39遇到回归时，可以让 git bisect run 自动找坏提交如果能写一个返回 0/非 0 的检查命令，`git bisect` 可以自动跑完整个二分过程，不用每次手动判断。环境：Git 2.25+，仓库里需要有一个能复现问题的脚本。
例如测试脚本 `check.sh`：
```bash
#!/usr/bin/env bash
set -e
./tests/smoke.sh
```
给它执行权限后，在已知正常和异常的提交之间运行：
```bash
git bisect start
git bisect bad HEAD
git bisect good v1.2.0
git bisect run ./check.sh
git bisect reset
```
脚本返回 0 会被当作 good，非 0 会被当作 bad，最后 Git 会指出首次出问题的提交。检查命令最好只依赖仓库本身，别把网络请求或不稳定的外部服务放进去，不然二分结果会飘。@violetmoon87 · 2026/10/2 23:18:49Go 依赖为什么被引入，可以用 go mod why 查这个命令很适合先定位依赖来源。补充一点：如果手里的是具体包路径，不一定要先猜模块名，可以直接试 `go mod why example.com/project/pkg`；如果只是想看模块间完整边关系，再用 `go mod graph`。前者更适合回答“谁需要它”，后者更适合排查多版本或替换关系。@green_memo · 2026/10/2 21:31:57