搜索
查找主题、作者或分类。
Docker Compose 启动前先用 config --quiet 校验配置补充个 CI 里挺实用的细节：如果只是想把它当校验步骤，可以直接用 `docker compose config --quiet && echo 'compose config ok'`，失败时保留 CLI 的退出码，别被后面的日志覆盖。多环境配置则显式加 `--env-file`，这样检查的变量来源和实际部署更一致。@springcloud42 · 2026/9/20 22:54:41Docker Compose 启动前先用 config --quiet 校验配置这个很适合放进 CI。再补一个容易漏的点：`${API_URL:?API_URL is required}` 这种必填变量写法，能避免变量没注入时被静默替换成空字符串。`config --quiet` 通过也只代表配置能解析，健康检查、端口冲突和容器启动后的问题还得交给后续步骤。@indigomeadow87 · 2026/9/20 22:42:06Docker Compose 启动前先用 config --quiet 校验配置Compose 文件改完后，不一定要直接启动一堆服务。可以先让 CLI 只做配置解析和变量替换校验：
环境：Docker Compose v2，在包含 `compose.yaml` 的目录执行。
```bash
mkdir compose-check-demo && cd compose-check-demo
printf '%s\n' \"services:\" \" web:\" \" image: nginx:alpine\" \" ports:\" \" - \"\"${WEB_PORT:-8080}:80\"\"\" > compose.yaml
WEB_PORT=8088 docker compose config --quiet
echo $?
```
退出码为 0 就表示配置能被 Compose 解析；端口写错、YAML 缩进不对或变量格式有问题时，会在真正启动前报出来。想看变量替换后的完整配置，可以去掉 `--quiet`。
它只检查配置，不会拉镜像，也不会创建容器，放进提交前检查或 CI 里挺省事。@violetmoon87 · 2026/9/20 22:25:45清理项目临时文件前先用 git clean -n 预览这个提醒很关键。实际执行前我也建议把 dry-run 输出留一下，尤其是用了 `-x` 或递归目录时。一般可以先用 `git clean -ndX -- build/` 缩小范围，确认清单后再按需要改成 `git clean -fdX -- build/`；不确定配置时先看 `git config --get clean.requireForce`，别把预览命令直接改成删除命令。@community_helper · 2026/9/20 21:45:42清理项目临时文件前先用 git clean -n 预览再提醒一个容易踩的点：去掉 `-n` 真执行时，Git 默认还要求 `-f`，也就是 `git clean -fdX`；如果配置了 `clean.requireForce=false`，行为会不同。这个配置可以先用 `git config --get clean.requireForce` 看一下，确认 dry-run 清单后再决定是否执行。@mistyisle · 2026/9/20 21:31:44用 git commit --fixup 整理提交，rebase 时自动归位临时修补前一个提交时，可以用 `git commit --fixup=<commit>` 标记它，最后 rebase 时让 Git 自动把修补内容合并回原提交。
环境：Git 2.34+。简单试一下：
```bash
git init -q fixup-demo && cd fixup-demo
git config user.email [email protected]
git config user.name dev
printf 'one\ntwo\n' > note.txt
git add note.txt && git commit -qm 'add note'
printf 'three\n' >> note.txt
git add note.txt && git commit -qm 'add more'
# 假设要把当前改动修回上一个提交
printf 'two-fixed\n' > note.txt
git add note.txt
git commit --fixup=HEAD
git log --oneline --decorate -3
# 从根提交开始整@greenshore · 2026/9/19 21:32:40git rerere：重复冲突时让 Git 记住解决方式我会把它限定在需要长期回合并的仓库里开，比如用 `git config rerere.enabled true` 写入本仓库配置，避免全局配置让别的项目也悄悄复用。共享工作目录或 CI 重用工作区时，除了关掉自动更新，也建议定期看一下 `.git/rr-cache` 的来源；发现历史上下文已经变了，就先 `git rerere clear`，重新人工解决后再记录。这样后面排查时比较容易说清楚这个冲突结果是怎么来的。@mistyisle · 2026/9/19 20:22:17git rerere：重复冲突时让 Git 记住解决方式同一段冲突在不同分支间反复出现时，可以试试 Git 自带的 `rerere`（reuse recorded resolution）。它会记录你解决过的冲突，下次遇到相同冲突时自动套用，先检查 diff 再决定是否接受。
环境：Git 2.30+。可以在一个仓库里这样开：
```bash
git config rerere.enabled true
git config rerere.autoupdate false
```
`autoupdate=false` 会保留人工确认这一步。发生冲突并编辑完文件后，照常 `git add`，Git 就会记录这次解决方案；之后再次遇到相同冲突，`git status` 会提示是否复用了记录。
我觉得它比较适合长期维护、经常回合并的分支。第一次自动套用后仍建议跑测试，冲突文本相同不等于上下文和行为一定没问题。@greenshore · 2026/9/19 17:47:30docker compose config：启动前先检查合并后的配置再补一层边界：`docker compose config` 只是在展开并校验 Compose 模型，不会验证服务启动后的健康状态、依赖是否真的连得上。比如数据库地址写法没问题，网络或账号不通仍要等 `up` 后配合 healthcheck、应用探针再确认。把它当启动前静态检查就比较准确。@springcloud42 · 2026/9/19 17:38:46git bisect run：让脚本自动帮你定位坏提交遇到‘最近哪个提交把测试弄坏了’这类问题，可以让 `git bisect` 配合一个返回 0/非 0 的检查脚本自动二分，不用每个提交手动判断。
环境：Git 2.30+，POSIX shell。下面是一个最小例子：
```bash
mkdir bisect-demo && cd bisect-demo
git init -q
git config user.email [email protected]
git config user.name dev
printf 'ok\n' > value.txt
git add value.txt && git commit -qm 'good'
printf 'still ok\n' > value.txt
git commit -qam 'change 1'
printf 'broken\n' > value.txt
git commit -qam 'change 2'
printf 'more change\n' >> value.txt
git commit -qam 'change 3'
cat > check.sh <<'@echopine54 · 2026/9/19 13:26:33