能安全删除的本地分支需满足：已合并到当前集成分支（如main）、未被他人引用、无近期推送且远程无对应分支；删除必须用git branch -d而非-d。
git branch --merged 能安全删掉的本地分支，不等于可以随便删；git rebase -i 整理提交前，必须确认目标分支未被他人基于它继续开发；历史重写不是“清理”，是“重写”，这点一旦忽略，协作就容易出事。
怎么判断哪些本地分支能安全删除
执行 git branch --merged 列出的分支，只是“已合并到当前分支”的分支，并不自动代表“已上线”或“不再需要”。比如你在 main 分支上运行该命令，它会包含所有已合入 main 的本地功能分支——但这些分支可能还在其他同事的本地仓库里被引用，或正用于灰度环境验证。
- 先切到
main（或你约定的集成分支）：git checkout main - 列出已合并分支：
git branch --merged | grep -v "^\*"，再手动过滤掉main、develop等保护分支 - 对每个候选分支，查它最后一次推送时间：
git log -1 --format="%ai %cn" <branch-name></branch-name>，若超过两周无更新，且git ls-remote origin <branch-name></branch-name>返回空，则基本可删 - 删除用
git branch -d <branch-name></branch-name>（拒绝强制删未合并分支），而非-D
rebase -i 合并提交时最常踩的三个坑
git rebase -i HEAD~n 是整理本地分支日志的主力命令，但它不是“魔法按钮”，误操作会导致提交 ID 全变、协作中断。
- 别在已推送到远程的分支上直接
rebase -i：哪怕只改一条 message，也会生成新 commit ID，git push会失败，必须加--force-with-lease，且要提前跟协作者同步 - 别把
squash和fixup混用：前者保留被 squash 提交的 message（需手动编辑），后者直接丢弃，容易漏掉关键变更说明 - 别跳过冲突检查：rebase 过程中遇到冲突，解决后必须
git add <file></file>再git rebase --continue；如果误用git commit，会多出一个“意外提交”，破坏线性历史
提交信息写不好，再干净的历史也白搭
提交信息不是备注，是给三个月后的自己和团队其他人看的决策快照。模糊的 git commit -m "fix bug" 或 "update"，等于没写。
- 首行控制在 50 字符内，用祈使句开头：
Add user auth middleware，不是Added...或Adding... - 空一行后写正文，每行 ≤72 字符，回答三个问题：为什么改？怎么改的？有没有副作用？例如：
Prevent concurrent session hijack by invalidating old tokens on login. Requires token store migration (see docs/migration/v2.3.md). - 关联需求/缺陷编号统一格式，如
[JIRA-1234]或#GH-567，方便 CI/CD 自动抓取上下文
孤儿分支（--orphan）不是日常工具，而是“断点重连”手段
git checkout --orphan 的真实用途，是当你想彻底放弃当前所有提交历史、但又不想丢掉工作区代码时的兜底方案——比如交付客户前清空内部调试痕迹，或迁移旧 VCS 时剥离冗余历史。
- 它不会删任何已有分支或提交，只是新建一个无祖先的分支指针，所有文件变成“未跟踪状态”
- 执行后必须
git add . && git commit -m "Initial commit"，否则git status会显示全部文件为 untracked - 后续推送到远程需强制：
git push --set-upstream origin new-main --force，且所有协作者必须重新 clone，不能简单git pull - 日常开发中绝对不要用它替代
rebase或reset，否则团队历史就真断了
git commit 前，多花 10 秒想清楚：这个提交，能不能让别人一眼看懂“为什么现在必须存在”。
