git branch --merged 漏掉刚合并分支不是 bug，而是因新合并提交尚未被索引刷新导致的延迟可见性；需 git fetch --all 或 git log --oneline main...feature/login 验证，不建议依赖该命令做自动化清理。
为什么 git branch --merged 会漏掉刚合并的分支
刚执行完 git merge feature/login，紧接着运行 git branch --merged 却没看到 feature/login，不是 bug，是 Git 的“延迟可见性”机制在起作用。Git 默认只把已合并的分支计入 --merged 列表，前提是该分支的 HEAD 提交**已被当前分支的提交图直接引用**——而 merge 操作刚完成时，新 commit 可能还没被索引刷新。
实操建议：
- 运行
git update-ref -d refs/heads/feature/login后再试（不推荐，破坏引用） - 更稳妥：先
git fetch --all同步远程引用，再git branch --merged - 或直接用
git log --oneline main...feature/login验证是否真无差异 - 别依赖
--merged做自动化清理，改用git for-each-ref --format='%(refname:short)' refs/heads/ --sort=-committerdate+ 提交时间判断
feature 分支命名后要不要加版本号或日期
加版本号（如 feature/v2-api-migration）或日期（feature/202606-login-redesign）看似清晰，实际会干扰 Git 的语义识别和工具链解析。主流 CI/CD 工具（GitHub Actions、GitLab CI）依赖正则匹配分支名触发流程，硬编码版本或日期会让规则变脆弱；更重要的是，分支名不该承担版本管理职责——那是 tag 和 release 分支的事。
实操建议：
- 坚持
type/description结构，如feature/user-session-expiry - 描述用名词短语，避免动词（不用
add-user-session），方便按字母序归类 - 若需区分迭代，靠 PR 标题或 commit message 说明，而非分支名
- 团队可约定前缀分级，如
feature/core/、feature/ui/，但层级不超过两段
git worktree 比 checkout 切分支快，但容易出什么问题
git worktree add 确实绕过了 checkout 的文件重写开销，尤其对大项目效果明显。但它引入了新的约束：每个 worktree 对应独立的 .git 引用，而 Git 不会自动同步这些 worktree 间的配置、stash 或未提交更改。
常见踩坑点：
- 在 worktree A 中执行
git config user.name，不会影响 worktree B —— 多个 worktree 共享 repo 配置，但本地配置（--local）是隔离的 -
git stash只作用于当前 worktree，切到另一个 worktree 后看不到之前的 stash - 误删 worktree 目录但没运行
git worktree remove，会导致git status报错 “worktree is locked” - CI 脚本若假设单工作区结构（如读取
$(pwd)/.git/HEAD），在 worktree 下路径会失效
删除远程分支后，本地还显示它怎么办
git push origin --delete feature/x 成功后，git branch -a 仍列出 origin/feature/x，这不是残留，是 Git 的远程引用缓存未更新。远程分支已删，但本地的 refs/remotes/origin/feature/x 还在磁盘上。
解决方法只有且必须是：
-
git fetch --prune origin（推荐）—— 清理所有过期远程追踪分支 - 或
git remote prune origin—— 效果相同，语义更直白 - 别用
git branch -d -r origin/feature/x，这是手动删引用，风险高且不触发 GC - 可设成默认行为：
git config --global fetch.prune true
真正麻烦的是那些长期没人碰、也没被 prune 过的仓库——它们积累的 stale refs 会拖慢 git branch -a 和 git log --all，这种问题往往要等到某次 git gc 才暴露出来。
