应删除远程所有非保护分支以简化管理，仅保留已上线、ci/cd构建及审计所需的分支；采用最小可行分支模型：唯一主干main、发布打tag、紧急修复用hotfix/、功能开发基于main新建feat/分支并强制rebase后合并。
旧分支太多，git log --oneline --all 看得眼花怎么办？
直接删掉远程所有非保护分支，比“慢慢合并”更省时间——尤其当历史提交混乱、多人长期在 feature 分支上直接改代码时。先用 git branch -r | grep -v '\->' | sed 's/origin\///' | grep -v 'main\|master\|develop' 列出所有待清理的远程分支名，再批量执行 git push origin --delete branch-name。注意：操作前确认没人正基于这些分支开发，否则会中断协作。
git rebase -i 重写历史后，如何避免队友 push 失败？
重写历史不是“做完就完事”，关键在同步通知和过渡期管理。必须明确告诉所有人：某分支（比如 main）将在 YYYY-MM-DD 18:00 后强制替换为新历史；在此之前所有人需完成本地未推送的提交，并在切换前执行 git fetch && git reset --hard origin/main。不这么做，他们继续 git push 会触发 non-fast-forward 拒绝，且 git pull 会引入重复 commit。
重构后要不要保留旧分支？哪些该留，哪些该删？
保留与否取决于是否还有可追溯性需求，而非“以防万一”。建议只留三类：
• 已上线但尚未下线的生产环境对应分支（如 release/v2.1）
• 被用于 CI/CD 构建的 tag 对应分支（如 build-20231001）
• 法规或审计要求存档的分支（需加 archive/ 前缀并设为 protected）
其余带 feature/、bugfix/、tmp- 的一律删除。别信“以后可能要用”，真要用时从 git reflog 或备份仓库恢复更快。
新分支模型怎么定，才不会三个月后又乱？
简单有效比“标准”更重要。推荐最小可行模型：
• 主干唯一：只用 main（不用 master 或 develop）
• 发布靠 tag：每次上线打 vX.Y.Z tag，不建 release/* 分支
• 紧急修复走 hotfix/，且必须基于最新 main + tag 检出，修完立刻 merge 回 main 并打新 tag
• 所有功能开发都基于 main 新建 feat/xxx，PR 合并前强制 rebase 到 main 头部
这套规则靠 CI 配置（如 GitHub Actions 检查 PR 是否已 rebase）来兜底，人管不住就让机器管。
真正难的不是命令怎么敲，而是说服团队接受“没有分支是常态”——一旦习惯每天从干净 main 拉新分支、当天合回，旧分支自然就没了存在理由。
