feature分支必须从develop拉取、命名含业务id、合并前rebase至最新develop、ci自动删除，否则将导致冲突、混乱与维护失效。
feature 分支不是“随便起个名就开干”的临时容器，它必须带明确生命周期、可追溯上下文、且与交付节奏强绑定。否则很快就会变成仓库里一堆 feature/login-v2、feature/login-fix、feature/login-again 的幽灵分支。
为什么 feature 分支要从 develop（而非 main）拉？
因为 main 是生产快照，只接受经过验证的发布内容；而 develop 才是当前所有待测功能的集成基线。从 main 拉 feature，等于默认跳过集成测试环节，后续合并时大概率遇到隐性冲突——比如你改了用户模型字段，但 develop 里已有另一个 PR 正在用新字段做校验逻辑，这种冲突 git merge 不报错，但运行时直接 panic。
- 正确做法：
git checkout -b feature/payment-alipay develop - 错误高发点：CI 流水线没强制校验 base 分支，导致有人从
main或旧feature分支拉出新分支 - 补救手段：用
git merge-base feature/payment-alipay develop手动检查是否真以develop为起点
feature 分支命名必须包含业务标识和唯一 ID
光写 feature/login 会迅速失效——没人知道这是第几次重构登录、对应哪个需求池里的任务、是否已废弃。团队协作中，分支名是第一层文档。
- 推荐格式：
feature/PROJ-123-login-refactor（Jira ID + 简短动宾短语） - 禁止使用模糊词：
feature/new、feature/fix、feature/temp - CI 可自动校验命名：通过正则
^feature\/[A-Z]+-\d+-[a-z]+(-[a-z]+)*$拦截不合规分支创建
合并前必须 rebase 到最新 develop，而不是直接 merge
直接 git merge develop 进 feature 分支，会在历史里塞进大量无关 commit，让后续 git bisect 失效，也掩盖真实变更范围。rebase 虽有风险，但在敏捷迭代中是必要代价。
- 安全操作流：
git checkout feature/PROJ-123-login-refactor→git fetch origin→git rebase origin/develop - 若遇冲突：只解决本次 feature 修改的文件，别碰
develop带来的其他文件变更 - 绝对禁止：
git push --force-with-lease origin feature/PROJ-123-login-refactor后不通知协作者——别人正在该分支上提交，会丢 commit
删除 feature 分支不能靠手动，得由 CI 自动触发
人总会忘记删分支，尤其当 PR 合并后被 QA 打回、又重开一个新 PR 时，旧分支就滞留了。50+ 个残留 feature 分支会让 git branch -a 输出失去可读性，也干扰自动化脚本判断活跃分支。
- 最佳实践：PR 合并到
develop后，CI 脚本自动执行git push origin --delete feature/PROJ-123-login-refactor - 本地同步清理：
git fetch -p（-p表示 prune，清除已不存在的远程追踪分支） - 容易被忽略的点：GitHub/GitLab 的 “Delete head branch after merge” 选项默认关闭，必须团队统一打开
feature 分支存活超过两个迭代周期，就要警惕：是不是需求卡点了？设计没对齐？还是测试环境一直没空出来？分支状态本身就是项目健康度的仪表盘。
