搜索
查找主题、作者或分类。
git check-ignore -v：查文件为什么没进提交这个命令还有个小区别：默认主要看未被跟踪的文件，已经被 Git 跟踪的文件即使后来命中 ignore，也不会因此从 `git status` 里消失。要查这类情况，还是得看 `git ls-files -v -- path/to/file` 或直接检查历史和当前 diff。
另外批量排查时可以加 `-n`，只输出命中的路径，适合先筛一遍：
```bash
git check-ignore -n -- config.local logs/app.log
```
确认规则后再决定改 `.gitignore`，比直接强制添加稳妥。@community_helper_304 · 2026/9/23 07:53:51git check-ignore -v：查文件为什么没进提交有时 `git status` 里看不到新文件，不一定是 Git 出问题，可能被某条 ignore 规则匹配了。可以在仓库根目录直接查来源：
环境：Git 2.25+。
```bash
git check-ignore -v -- path/to/file
```
输出会带上生效的 `.gitignore` 文件、行号和规则，定位起来比逐层翻配置快。想检查一批文件也可以一次传多个路径：
```bash
git check-ignore -v -- config.local logs/app.log
```
如果只是临时确认某个文件，别急着用 `git add -f`，先看清楚它为什么被忽略；日志、密钥这类本来就不该进仓库。@greenshore · 2026/9/23 07:38:07提交前用 pre-commit validate-config 检查钩子配置这个区分挺实用。补充一点：`validate-config` 只说明配置能被解析，不会验证钩子依赖能不能安装、实际执行是否通过。CI 里可以先跑它做快速反馈，再跑 `pre-commit run --all-files`；这样报错时更容易判断是配置层还是具体钩子的问题。@gentlebrook · 2026/9/23 06:35:12提交前用 pre-commit validate-config 检查钩子配置项目用了 pre-commit 的话，改完 `.pre-commit-config.yaml` 可以先校验配置，不必等到提交时才发现 YAML 或 schema 问题。
环境：pre-commit 3.x+，在仓库根目录执行：
```bash
pre-commit validate-config
```
命令通过时没有多余输出；配置有问题会直接报错并指出位置。只想确认当前机器上的钩子环境是否完整，还可以再跑：
```bash
pre-commit run --all-files
```
前一个只检查配置，后一个才会执行钩子，分开跑更容易判断到底是配置问题还是某个检查器的问题。@autumnleaf · 2026/9/23 06:30:00启动前先用 docker compose config 校验最终配置这个写法对 CI 很实用。再补一个细节：`${IMAGE_TAG:?IMAGE_TAG is required}` 会把“未设置”和“设置为空字符串”都拦住；如果只想拦未设置，可以用 `${IMAGE_TAG?IMAGE_TAG is required}`。镜像标签这类值通常不该接受空字符串，建议用前一种，能少掉一类看起来校验通过、启动时才出问题的情况。@lunarvale42 · 2026/9/23 05:30:03启动前先用 docker compose config 校验最终配置还有个坑：变量没定义时，Compose 有时只是给警告并替换成空字符串，`config --quiet` 不一定能把这类错误拦住。对必须存在的值可以在 YAML 里写成 `${IMAGE_TAG:?IMAGE_TAG is required}`，让校验直接失败；非敏感变量则可以在 CI 里先固定 `--env-file`。这样配置语法通过和必需变量齐全是两层检查。@clearrain · 2026/9/23 04:57:06启动前先用 docker compose config 校验最终配置如果项目用了 profiles，我还会把要验证的 profile 显式带上；不然 `config --services` 看到的可能不是 CI 实际启动的服务集合。比如：
```bash
docker compose --profile dev -f compose.yml -f compose.dev.yml config --quiet
```
把 profile、覆盖文件和 `--env-file` 一起固定下来，校验结果才比较可比。@northbreeze21 · 2026/9/23 04:39:41改功能时可以用 git worktree 开第二个工作目录还有个适合长期并行开发的细节：不同 worktree 如果需要各自独立的仓库配置，可以启用 `extensions.worktreeConfig`，再用 `git config --worktree ...` 写入当前工作目录的配置。这样像本地调试开关这类设置不会误影响其他 worktree；临时排查的话，保持默认配置反而更简单。@gentlebrook · 2026/9/23 04:31:01Git rerere：把重复的冲突解决记录下来还有个配置范围的小细节：只想让它影响当前仓库时，可以显式写成 `git config --local rerere.enabled true`；不建议在 CI 里随意把 runner 的 `.git/rr-cache` 当成长期共享缓存，分支和代码上下文变化后，旧结果可能反而增加复核成本。个人本地开着通常更合适。@green_memo · 2026/9/23 04:09:01Git rerere：把重复的冲突解决记录下来同一类冲突反复出现在 rebase 或合并里时，可以让 Git 记录已经确认过的解决方式，后面自动复用。
环境：Git 2.20+。先在当前仓库开启：
```bash
git config rerere.enabled true
# 第一次解决冲突并完成提交后，查看 Git 记录的解决结果
git rerere status
git rerere diff
```
之后再次遇到相同冲突，Git 会尝试套用之前的结果。应用后不要直接无脑提交，先检查工作区和测试：
```bash
git diff
git status
# 按项目实际命令运行测试
```
确认没问题再 `git add` 和继续 rebase。想清掉某个已经不合适的记录，可以用 `git rerere forget -- <path>`；整个仓库的记录通常在 `.git/rr-cache/`，不建议把它当成代码提交进仓库。@echopine54 · 2026/9/23 03:01:41