feature分支应适时删除：合并入develop且经CI验证后由发起人主动删本地与远程分支；未合并则用archive/前缀归档，避免早删失上下文或晚删致混乱。
feature分支该不该删？删早了还是删晚了
feature分支不是“用完即弃”的临时工，而是有明确生命周期的协作契约。删得太早（比如刚合进develop就删），会导致后续排查问题时无法快速定位原始上下文；删得太晚（比如长期滞留几十个未清理分支），又会让git branch -a输出变成考古现场，干扰新人理解项目结构。
标准做法是：在merge --no-ff成功推送到develop后，由发起人主动删除本地和远程的feature/xxx分支。前提是这次合并已通过CI流水线验证、且develop分支当前状态稳定。
- 必须确认
git log develop --oneline | head -5里能看到你这次合并的commit，且其message含Merge branch 'feature/login-refactor' - 避免用
git push origin :feature/login-refactor直接删远程分支——先git fetch --prune同步远端状态，再执行删除，防止误删他人正在使用的同名分支 - CI脚本里可加一道检查：
git ls-remote --heads origin feature/若返回非空，说明还有残留，自动告警
feature分支命名怎么防冲突、防歧义
命名不是为了好看，是为了让git branch列表一眼能回答三个问题：谁建的、干啥用的、还在不在维护。用feature/user-profile-v2比feature/new-ui强，但还不够。
推荐格式：feature/{作者缩写}/{模块}-{简短目标}，例如feature/yzh/auth-token-refresh。这样既避免多人用feature/login互相覆盖，又能在PR标题、commit message、CI日志里形成统一索引。
- 禁止使用模糊词：
fix、update、new、v2单独出现（v2必须绑定具体模块） - 长度控制在30字符内，Git对分支名本身无硬限制，但GitHub/GitLab UI会截断显示
- 如果涉及跨模块改动（如同时改前端路由+后端鉴权），优先拆成多个feature分支，而非用
feature/frontend-backend-sync这种大而全命名
feature分支卡在半路怎么办：没合进develop，但也不能直接丢
常见场景：分支开发了一半，需求临时冻结、负责人离职、技术方案被否。这时候硬删分支等于丢掉所有中间状态；一直挂着又污染分支列表。关键不是“保不保留”，而是“怎么保留得有用”。
正确做法是打一个带语义的tag，并归档到专用分支前缀下：
- 用
git tag archive/feature-20260715-auth-mfa feature/auth-mfa标记快照 - 把原分支重命名为
archive/feature-auth-mfa-20260715（用git branch -m），并push到远程 - 在README或内部Wiki中记录该归档分支的背景、中断原因、当前状态（如“已实现token校验逻辑，未完成UI适配”）
这样既不干扰日常开发，又保证未来有人想复用这段代码时，能通过git tag -l "archive/*"快速找到，而不是靠git reflog大海捞针。
feature分支要不要rebase？什么时候必须avoid
rebase不是优雅的代名词，而是风险开关。它只在一种情况下安全：分支尚未被其他人基于它创建新工作。一旦feature/x被团队其他成员checkout过，rebase就会改写历史，导致他们本地分支与远程失联。
判断依据很简单：git ls-remote origin feature/x返回的commit hash，是否和你本地git rev-parse feature/x一致。不一致就说明别人已经基于它工作，此时只能merge。
- CI流水线配置里禁用
git push --force-with-lease，防止误操作覆盖他人分支 - 如果必须清理提交历史（比如把调试用的
console.log提交删掉），应在合并前完成，且仅限本地操作；合入develop后的rebase一律禁止 - 某些CI工具（如GitLab CI）会为每个feature分支生成独立pipeline，这类场景下rebase可能导致pipeline ID错乱，触发重复构建
git checkout -b前，多花三秒想清楚：这个分支的生命终点在哪？谁会用它？它失效后，别人怎么知道它曾经存在过？ 
