Post-Merge Branch Naming 综合评估
核心用法
post-merge-rename 是一款 Git 工作流辅助工具，专为 "永不删除分支" 的代码管理哲学设计。它在 PR 合并后自动扫描本地仓库，将已合并分支重命名为 branch-name--merged-YYYY-MM-DD 格式，并同步到远程仓库。
三种执行模式：
- 完整扫描模式：
bash scripts/post-merge-rename.sh—— 自动发现并处理所有已合并分支 - 预览模式：
--dry-run—— 零风险预览即将重命名的分支列表 - 单分支模式：
bash scripts/post-merge-rename.sh <branch>—— 精确指定目标分支
工作流程：
1. 比对当前分支与 main 的合并关系
2. 智能跳过已含 --merged- 标记的分支（防重复处理）
3. 从 Git 日志提取精确合并日期
4. 执行本地重命名 → 推送新分支 → 删除远程旧分支名
显著优点
| 维度 | 优势 |
|------|------|
| **历史完整性** | 分支引用永久保留，可随时回溯任意时间点的开发上下文 |
| **审计友好** | 日期后缀天然形成时间轴，便于合规审查与版本追溯 |
| **零破坏性** | 不执行 `git branch -D`，彻底避免误删未合并代码的风险 |
| **自动化集成** | 作为 `wip-release` 流水线第 10 步，无缝融入 CI/CD |
| **透明可控** | `--dry-run` 机制让运维人员完全掌握变更范围 |
潜在缺点与局限性
| 问题 | 说明 |
|------|------|
| **命名污染** | 长期运行后远程仓库积累大量 `--merged-` 分支，可能影响分支列表可读性 |
| **存储开销** | 保留所有分支引用意味着 Git 对象库持续膨胀，大型项目需配合 `git gc` 策略 |
| **权限依赖** | 需具备远程分支删除/创建权限，企业内网可能受 Git 策略限制 |
| **日期精度** | 依赖 Git 合并提交的时间戳，若使用 `rebase` 或 `fast-forward` 策略可能产生歧义 |
| **Bash 依赖** | 跨平台兼容性受限，Windows 环境需 WSL 或 Git Bash |
适合人群
- 合规驱动型团队：金融、医疗等需保留完整开发审计链的行业
- 大型遗留项目：需要追溯多年前功能分支起源的维护团队
- Git 工作流规范制定者：希望建立 "安全删除" 替代方案的技术负责人
- DevOps 工程师：寻求与现有发布流水线集成的自动化工具
常规风险
- 远程同步失败：网络中断或权限不足时，可能出现本地已重命名但远程未更新的不一致状态
- 并发冲突：多人同时操作同一分支时，后执行者可能遇到引用冲突
- 误识别风险：若分支命名巧合包含
--merged-字符串，将被错误跳过 - 脚本注入：输入
<branch>参数时若未做校验，理论上存在命令注入可能（需审计具体实现）