必须显式执行git push origin --delete清理远程分支，因git设计上本地与远程状态分离；删后须git fetch --prune同步清理本地远程跟踪引用，且需跳过受保护分支与主干分支。
远程分支太多，git branch -r 看得眼花，怎么安全清掉？
直接删比“慢慢合并”更高效，尤其当旧分支提交混乱、多人长期在上面改代码时。先用这条命令列出所有待清理的远程分支：git branch -r | grep -v '\->' | sed 's/origin\///' | grep -v 'main\|master\|develop'
再批量删除：git push origin --delete branch-name
注意三点：
• 操作前确认没人正基于这些分支开发，否则会中断协作
• 保护分支（如 main、release/v2.1）必须跳过
• 删除后建议同步更新本地远程追踪分支：git fetch --prune
重构后要不要保留旧分支？哪些该留，哪些该删？
保留与否取决于可追溯性需求，不是“以防万一”。只留三类：
• 已上线但尚未下线的生产环境对应分支（如 release/v2.1）
• 被 CI/CD 构建明确引用的 tag 对应分支（如 build-20231001）
• 法规或审计要求存档的分支（需加 archive/ 前缀并设为 protected）
其余带 feature/、bugfix/、tmp- 的一律删除。真要用时，从 git reflog 或备份仓库恢复比翻旧分支快得多。
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
新分支模型定错了，三个月后又乱，怎么办？
简单有效比“标准”更重要。最小可行模型推荐：
• 主干唯一：只用 main，不用 master 或 develop
• 发布靠 tag：每次上线打 vX.Y.Z，不建 release/* 分支
• 紧急修复走 hotfix/，且必须基于最新 main + 对应 tag 检出，修完立刻 merge 回 main 并打新 tag
• 所有功能开发都基于 main 新建 feat/xxx，PR 合并前强制 rebase 到 main 头部
这套规则靠 CI 配置兜底（比如 GitHub Actions 检查 PR 是否已 rebase），人管不住就让机器管。
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，污染历史。
