git分支生命周期需动态演进：feature/分支合并后须立即删除本地及远程；release/分支仅限冻结至发布窗口，同步master与develop后即删；hotfix/必须从master创建并双合入，完成后立刻删除。
Git分支生命周期不是“设好就完事”的静态规则，而是必须随每次提交、合并、删除动态演进的活流程。不严格执行终结阶段，feature/ 和 hotfix/ 分支会迅速堆积成“分支沼泽”，直接拖慢 git log、干扰 CI 识别、甚至导致误合。
feature 分支必须在 merge 后立即删除
开发完成并成功合并到 develop 后，该 feature/xxx 分支就失去存在意义。保留它只会带来三类实际问题：一是远程仓库分支列表膨胀，git branch -r 输出难以扫读；二是新人容易误切旧分支继续提交；三是 CI/CD 工具（如 Jenkins 或 GitLab CI）可能因分支名匹配规则触发非预期构建。
- 本地删除用
git branch -d feature/login（-d要求已合并，更安全） - 远程删除必须显式执行
git push origin --delete feature/login - 别依赖 IDE 自动清理——多数 IDE 默认不删远程分支
- 如果合并后发现遗漏提交，应基于
develop新建分支，而不是复用旧feature/
release 分支的生命周期严格限定在“冻结→验证→发布”窗口内
release/x.y.z 不是长期驻留分支，它的存在只服务于一个目标：把一批功能从 develop 隔离出来，做最终测试、文档更新、版本号打标。一旦 master 和 develop 都完成同步，这个分支就必须消失。
- 创建时必须基于
develop：git checkout -b release/1.2.0 develop - 合并到
master后，必须立刻打 tag：git tag v1.2.0（tag 比分支更不可变，才是真实版本锚点） - 合并回
develop是强制步骤——否则develop会丢失 release 中的修复（比如文案调整、兼容性补丁） - 所有操作完成后，本地和远程都需执行
git branch -d release/1.2.0和git push origin --delete release/1.2.0
hotfix 分支必须从 master 创建，且只能合并回 master 和 develop
线上出问题时，时间就是关键。任何绕开 master 起点的 hotfix/（比如从 develop 或某个 feature/ 拉），都会导致修复漏发、版本错乱，甚至引发二次故障。
- 正确起点：
git checkout -b hotfix/db-connection master - 修复提交后，先合入
master（快速上线）：git checkout master && git merge --no-ff hotfix/db-connection - 再合入
develop（避免下次迭代重复踩坑）：git checkout develop && git merge --no-ff hotfix/db-connection - 合并完成即删分支——
hotfix/多存一天，就多一分被误用风险
真正难的不是记住这些步骤，而是在每天几十次 git push 和 PR 合并中，让每个成员都把“删分支”当作和“写 commit message”一样自然的动作。没人会为没删的 feature/ 报警，但它会在第 37 个未清理分支出现时，让新成员第一次 git fetch 就卡住两秒——这种延迟，就是规范失效最真实的代价。
