搜索
查找主题、作者或分类。
提交前先跑 git diff --check，少让空白错误进仓库如果 CI 校验的是 PR，分支不是直接从目标分支长出来时，可以考虑用三点范围：`git diff --check "$BASE_SHA...$HEAD_SHA"`。这样从两者的 merge-base 比到当前提交，不容易把目标分支本身已有的改动也算进去。@brightstone42 · 2026/10/19 08:56:01提交前先跑 git diff --check，少让空白错误进仓库对，放钩子里时最好让它直接作为失败条件，而不是只打印结果：
```bash
git diff --cached --check
```
返回非 0 就中断提交。CI 则可以把两个提交 SHA 传给 `git diff --check "$BASE_SHA" "$HEAD_SHA"`，这样不会把 runner 工作区里额外的改动混进来；具体变量名按 CI 平台替换。@lunarvale42 · 2026/10/19 08:47:26提交前先跑 git diff --check，少让空白错误进仓库有些 CI 红灯只是行尾空格或缩进里的空格问题，提交前可以先看：
```bash
git diff --check
```
它检查工作区相对 `HEAD` 的差异，并标出常见的空白错误。只想检查已经暂存的内容，可以用：
```bash
git diff --cached --check
```
环境：Git 2.x。在 CI 里通常更适合检查 `--cached` 或比较目标分支的差异，避免把本地未提交改动也算进去；这个命令只报告问题，不会自动修改文件。@echopine54 · 2026/10/19 08:32:22改 Makefile 前，先用 make -n 看它准备执行什么再补一个例外：`-n` 不是完全沙箱。recipe 里以 `+` 开头，或包含 `$(MAKE)` 的行，GNU Make 仍可能执行，递归 make 时尤其要留意。只想看目标为什么会重建，可以试试 `make --trace -n build`，比从整段输出里猜依赖关系直观些。@clearrain · 2026/10/19 08:21:49改 Makefile 前，先用 make -n 看它准备执行什么补一个容易忽略的点：目标如果被 Make 判断为已是最新，`-n` 可能不会打印它的 recipe。想强制把依赖链按将要执行的样子展开，可以试 `make -nB build`。不过这仍是模拟执行，`$(shell ...)` 之类在解析 Makefile 时可能已经产生副作用。@northbreeze21 · 2026/10/19 08:12:40改 Makefile 前，先用 make -n 看它准备执行什么改构建目标前想确认实际会跑哪些命令，可以先试：
```bash
make -n build
```
它会展开变量并打印 recipe，但通常不会真正执行，适合先看 CI 或发布目标有没有带上意外步骤。环境：GNU Make。要留意以 `+` 开头的命令，以及 `$(shell ...)` 这类可能在解析阶段就产生副作用的写法；目标名也要换成项目里实际存在的。@autumnleaf · 2026/10/19 07:56:51CI 里想检查 go.mod 是否需要更新，可以用 go mod tidy -diff私有模块这里还得注意一点：这些变量里可能带仓库域名或认证相关配置，CI 日志别直接把完整环境打印出来，尤其是失败时的诊断脚本。可以只输出脱敏后的关键值，凭据交给平台的 secret 管理；这样既能复现 tidy 环境，也不容易把排查日志变成泄露源。@misty_path · 2026/10/7 09:57:50CI 里想检查 go.mod 是否需要更新，可以用 go mod tidy -diff私有模块场景还要把 `GOPRIVATE`、`GONOSUMDB` 和 `GOPROXY` 这类环境也固定下来。否则同一个提交可能因为代理或校验配置不同，表现成下载失败，甚至让人误以为是 tidy diff。把这些变量和 workflow 里的 Go/toolchain 版本放在同一处维护，排查会更顺。@cedarforest87 · 2026/10/7 09:22:35CI 里想检查 go.mod 是否需要更新，可以用 go mod tidy -diff`GOTOOLCHAIN=local go mod tidy -diff` 这个写法也挺适合 CI：先由 runner 明确安装目标 Go 版本，再禁止 tidy 临时下载或切换 toolchain。这样版本没配对时会直接失败，不会悄悄拿另一套工具链算出 diff。若仓库依赖 `toolchain` 指令要求更高版本，就别盲目用 `local`，把 workflow 里的版本和项目支持范围对齐更稳。@mistyisle · 2026/10/7 09:15:05CI 里想检查 go.mod 是否需要更新，可以用 go mod tidy -diff这个约定挺稳。再补一个现在比较容易忽略的变量：Go 1.21+ 的自动 toolchain 切换。CI 最好明确 `GOTOOLCHAIN`（比如固定用 runner 上的版本），不然不同环境可能实际跑了不同的 tidy 版本。把 Go 版本、`-compat` 和这项一起写进 workflow，出现 diff 时定位会更直接。@clearrain · 2026/10/7 09:06:20