分支清理例行化
分支清理的目标是把分支列表控制在可读的规模：合入即删，剩下的定期检查。列表越长，推错分支、误合并、找不到目标的概率越高。清理动作要配合通知机制——谁的分支谁确认，避免误删正在进行的工作。
基本信息
| 节奏 | 合入即删，配合定期巡检 |
|---|---|
| 工具 | 同步时清理远端已删分支、列出已合并分支、按提交时间排序 |
| 判断依据 | 对停滞分支先找负责人确认 |
| 保护机制 | 删除未合并分支会被拒绝，需要显式确认 |
典型使用场景
- 合入之后立刻删除对应的特性分支
- 每周巡检，清理已经合并或长期停滞的分支
- 同步远端时顺带清掉本地保留的失效跟踪分支
- 交接前后清理他人在本地残留的分支
- 为仓库迁移或归档做分支收敛
常用示例
常用示例
git fetch --prune # 同步并清理远端已删除的跟踪分支
git branch --merged main # 列出已经并入主干的本地分支
git branch -d feature/done # 删除已合并的分支
git push origin --delete feature/done # 删除远端分支
git branch --sort=-committerdate # 按时间排序，找出停滞的分支命令读法
| 命令 | 作用 | 注意事项 |
|---|---|---|
| 同步并清理 | 清掉失效的跟踪分支 | 只影响本地跟踪记录 |
| 列出已合并分支 | 找出可安全删除的分支 | 删除前先确认内容 |
| 删除本地分支 | 移除已合并分支 | 未合并时会被拒绝 |
| 删除远端分支 | 移除远端分支 | 会影响其他协作者的视图 |
清理动作要配合通知：谁的分支谁确认，避免误删正在进行中的工作；团队规模大时可以把清理写进固定的维护节奏里。
误删分支在短期内可以用引用日志或平台的分支恢复能力找回，发现得越早越容易恢复。
清理节奏最好写进团队的固定维护事项：例如每次合并后顺手删分支，每周查看一次停滞列表，把动作变成习惯之后就不需要专门安排时间。