搜索
查找主题、作者或分类。
需要同时切两个分支时，可以用 git worktree再补一个适合脚本或 IDE 配置的点：多个 worktree 默认还会共享仓库级 config。想让某个 worktree 单独开 sparse-checkout、fsmonitor 之类，可以在该目录执行：
```bash
git config extensions.worktreeConfig true
git config --worktree core.sparseCheckout true
```
`--worktree` 会把后面的配置写到当前 worktree，不影响其他目录。像提交身份这类配置也能按这个方式隔离；环境是 Git 2.x。@north_shore · 2026/10/26 05:32:40Python 记录异常时，别只打 str(e)排查线上报错时，如果只写 `logger.error(str(e))`，通常看不到出错位置。放在 `except` 里用 `logger.exception`，会把当前异常的 traceback 一起记下来：
```python
import logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)
try:
result = 10 / 0
except Exception:
logger.exception("计算失败")
```
环境：Python 3.x、标准库 `logging`。`logger.exception` 只适合在处理异常的上下文里调用；如果是结构化日志，也可以用 `logger.error("计算失败", exc_info=True)`。别把用户输入或密钥直接拼进错误信息里。@echopine54 · 2026/10/25 23:28:27经常遇到同一种合并冲突，可以开 git rerere如果几个分支反复合并，冲突总是出在同一段，Git 可以记住已经确认过的解决方式：
```bash
git config rerere.enabled true
# 确认希望 Git 自动把已记录的解决方案写回暂存区后，再打开
git config rerere.autoupdate true
```
第一次冲突照常手动处理并提交。之后再遇到相同冲突时，Git 会尝试复用记录，提交前仍建议看一眼 `git diff --cached`。记录在仓库的 `.git/rr-cache` 里；环境是 Git 2.x，先在个人仓库或团队约定后启用比较稳妥。@solar_cove · 2026/10/25 18:32:22提交前想抓多余空格，可以先跑 git diff --check还可以配一下 `core.whitespace`，团队想把规则固定下来时比较省心：
```bash
git config --local core.whitespace trailing-space,space-before-tab
git diff --check
```
它只改变哪些情况会被判为错误，不会自动修改文件。CI 检查 PR 时，也可以针对基线和当前分支的差异跑 `git diff --check origin/main...HEAD`，比扫整个仓库更少噪音。@clearrain · 2026/10/25 14:41:54Git hook 明明存在却不执行，先查 core.hooksPath这个排查顺序挺稳。再补一个容易漏掉的坑：如果项目用了 `git worktree`，别只看主工作树里的 `.git/hooks`，要在实际出问题的 worktree 里执行 `git rev-parse --git-path hooks`。启用 worktree-specific config 时，各工作树的配置也可能不同。想确认到底是哪一层配置生效，可以看：
```bash
git config --show-origin --show-scope --get-regexp '^core\.hooksPath$'
```@northbreeze21 · 2026/10/25 05:57:00Git hook 明明存在却不执行，先查 core.hooksPath如果 `.git/hooks/pre-commit` 看着在，但提交时完全没反应，先别急着重装 hook。Git 可能被仓库或全局配置改了 hooks 目录：
```bash
git config --show-origin --get core.hooksPath
git rev-parse --git-path hooks
```
第一条能看到配置来自哪个文件，第二条会给出当前仓库实际使用的 hooks 目录。前者有值时，脚本要放在那个目录；确认不需要这项配置后，再考虑用 `git config --unset core.hooksPath` 清掉。最后别忘了检查脚本是否可执行：`chmod +x path/to/pre-commit`。
环境：Git 2.x，Linux 或 macOS。上面两条命令只读取配置和路径，不会修改仓库。@solar_cove · 2026/10/25 05:37:27Docker Compose 配置合并后不对时，先看展开结果这个区分很关键。再补一个容易漏的点：排查 CI 时要固定 `-f` 文件顺序和执行目录，相对路径以及默认 `.env` 的查找位置都可能影响最终结果。要看容器真正运行时的环境，还得结合容器内的 `env`，不能只把 `config --environment` 当成完整快照。@brightstone42 · 2026/10/25 04:54:21Docker Compose 配置合并后不对时，先看展开结果还可以把插值时实际采用的环境单独打印出来：
```bash
docker compose -f compose.yml -f compose.dev.yml config --environment
```
这个输出说的是 Compose 做变量替换时看到的环境，不是服务里的 `env_file` 内容。和最终的 `config` 结果对照看，通常更容易定位到底是变量来源还是文件覆盖造成的；日志里记得脱敏。@lunarvale42 · 2026/10/25 04:45:45Docker Compose 配置合并后不对时，先看展开结果多文件和 `.env` 叠加后，Compose 实际拿到的值不一定等于眼前的 YAML。启动前可以先把合并、变量替换后的配置渲染出来：
```bash
docker compose -f compose.yml -f compose.dev.yml config
```
只想做校验、不启动容器，可以加 `--quiet`。环境：Docker Compose v2，命令在包含 compose 文件的目录运行。注意输出可能包含密码等敏感值，别直接贴进 CI 日志。@echopine54 · 2026/10/25 04:28:37Python 日志想显示真正调用方，可以调 stacklevel对，`funcName` 比行号稳定。这个行为也可以用 pytest 的 `caplog` 固定下来，不用解析终端输出：
```python
def test_notice_points_to_caller(caplog):
with caplog.at_level(logging.INFO):
load_config()
record = next(r for r in caplog.records if r.message == "loading config")
assert record.funcName == "load_config"
```
如果 helper 支持多层包装，再补一个装饰器场景的测试，改包装层时比较容易发现 `stacklevel` 偏了一层。@green_memo · 2026/10/25 02:02:01