正确做法是新建规范命名的bugfix分支，以当前feature分支head为起点，完成修复后关闭原pr并新开pr指向develop；hotfix场景下不可直接由feature衍生，必须从main创建并cherry-pick修复提交。
功能分支开发中途发现严重 Bug，需要紧急修复并合入当前版本？别直接改 feature/ 分支名或硬切新分支——这会导致 CI/CD 失效、PR 关联丢失、Git 历史混乱。正确做法是保留原分支生命周期，仅通过语义化重命名 + 明确合并路径来完成“功能转修复”的意图传达。
为什么不能直接把 feature/xxx 改成 fix/xxx
Git 分支名本质是引用（ref），重命名操作 git branch -m 不会自动更新远程跟踪分支、CI 触发规则、Jira 关联、PR 标题或已提交的 commit message。更关键的是：feature/ 分支默认预期合并到 develop，而修复类分支（bugfix/ 或 hotfix/）通常有不同目标分支和发布流程。强行混用会破坏自动化判断逻辑。
feature 分支如何合规转为 bugfix 分支
核心原则：不改历史，只改命名 + 明确用途 + 调整合并策略。实际操作分三步：
- 新建规范命名的
bugfix/分支，以当前feature/xxx的 HEAD 为起点：git checkout -b bugfix/xxx-critical-login-fail origin/feature/xxx - 在新分支上完成修复，并确保 commit message 明确标注问题来源（例如：
fix: prevent null pointer in login flow (refs #ISSUE-789)） - 关闭原
feature/xxxPR，新开 PR 指向develop（非main），标题注明“紧急修复替代方案”，并在描述中说明迁移原因
hotfix 场景下 feature 分支能否转 hotfix
能，但必须满足两个硬条件：
- 该 Bug 已在线上
main分支复现（不是仅存在于未合并的功能代码中） - 修复必须从
main创建，而非从feature/xxx直接衍生 —— 否则无法保证 patch 可单独回滚且不影响其他功能
正确做法：git checkout main && git checkout -b hotfix/login-crash-202607，然后 cherry-pick feature/xxx 中已验证的修复 commit（git cherry-pick <commit-hash></commit-hash>），再测试、提交、PR 到 main 和 develop。
团队协作中最容易被忽略的细节
分支命名只是表象，真正容易出错的是上下文同步：Jira ticket 状态没更新、CI 配置没适配新前缀、旧 PR 未关闭导致重复合并、甚至有人继续往原 feature/xxx 推送代码。只要分支生命周期没终结（即未被删除且仍有活跃引用），它就仍是有效分支——命名变更本身不带来任何流程约束力。
