特性分支必须规范命名、限时生命周期、强制rebase+squash合并、及时删除。命名如feature/auth-sso-integration，周期控制在3–7天，合并前需rebase origin/main并压缩提交，PR后勾选删除源分支。
特性分支（feature branch）不是“用不用”的问题，而是“怎么用才不踩坑”的问题。它本身轻量、廉价，但一旦命名混乱、生命周期失控、合并策略随意，就会变成协作瓶颈。
feature/xxx 分支命名必须带作用域和语义
很多人直接 git checkout -b feature/login，看似没问题，但当团队有 20 个登录相关改动（SSO、密码重置、MFA、第三方绑定）时，这个分支名就失去区分度。命名应体现「谁在做什么、影响什么模块」。
- 推荐格式：
feature/auth-sso-integration、feature/api-v2-user-endpoints - 避免：
feature/new、feature/fix、feature/123（除非项目强制关联 issue 编号且系统自动解析） - 斜杠前缀（
feature/）必须保留——这是 Git 工具链（如 CI/CD 过滤、branch protection rules）识别分支用途的关键标识
分支生命周期要主动收口，不能“长期挂起”
一个 feature/xxx 分支从创建到合并，理想周期应控制在 3–7 天。超过 10 天未更新的分支，大概率已偏离 main 或 develop 当前状态，强行合并极易引入隐性冲突或逻辑断裂。
- 每天至少一次
git pull origin main（或develop）并rebase，保持提交线性干净 - 禁止在 feature 分支上直接
merge origin/main—— 这会污染历史，产生无意义的 merge commit - CI 检查失败时，不要绕过修复直接 push force：很多团队用
pre-commit或husky拦截 lint/format，但忘了git push --force-with-lease也可能覆盖他人新提交
合并前必须做两件事：rebase + 强制 squash
直接 git merge feature/xxx 到 main，会把开发过程中的调试提交、临时注释、反复修改都塞进主干历史，既难追溯，也破坏可读性。GitHub/GitLab 的 PR 合并界面默认提供 squash option，但很多人没意识到它的必要性。
- 本地 rebase 是为了消除中间冲突解决痕迹：
git rebase -i origin/main，把多个小提交压缩成 1–3 个语义清晰的提交 - 提交信息必须符合 Conventional Commits：
feat(auth): add SSO login via Google OAuth，而非fix bug或update files - 即使使用
git merge --no-ff，也要确保合并前已完成 rebase 和 squash；否则--no-ff只是多了一个无信息量的 merge commit
删除分支的时机比创建更重要
分支合并后不删，是团队仓库最普遍的“慢性病”。残留的 feature/xxx 分支不仅干扰 git branch -a 输出，更会在下次误操作时被重新 checkout，导致旧逻辑复活。
- GitHub/GitLab PR 合并页面右下角有 “Delete source branch” 勾选框——务必勾选，这是最安全的删除方式
- 本地删除命令是
git branch -d feature/xxx（-D强制删除未合并分支需谨慎） - 远程删除必须显式执行：
git push origin --delete feature/xxx；仅删本地不等于删远程 - 建议在 CI 流水线末尾加一步脚本，自动清理已合并的远程 feature 分支（需权限配置）
真正难的不是建分支，而是让每个分支都有明确的出生证明（命名）、成长日志（rebase/squash）、死亡通告（删除）。没人会检查你有没有 git checkout -b，但所有人会感知到你留下的分支垃圾和混乱历史。
