git分支管理需适配团队节奏：feature分支应从develop切出（非main），命名推荐feature/模块-功能-行为格式，合并策略须统一，release分支仅短期保留，且分支规则须嵌入ci自动化校验。
Git 分支管理没有“标准答案”，只有“适配当前团队节奏的答案”。盲目套用 Git Flow 或直接全用 main 分支，都容易在 2–3 个月后引发合并冲突爆炸、发布回滚困难、新人不敢合代码等问题。
feature 分支该从哪个分支切？
绝大多数项目应该从 develop（或 next）切，而不是 main。因为 main 代表生产就绪状态，功能未测完、CI 未过、文档未更新的代码不该污染它。
- 例外情况：紧急 hotfix 必须从
main切，修复后同时合入main和develop - 如果团队没设
develop，又坚持单主干（Trunk-Based Development），那就必须从main切——但前提是所有提交都带自动化测试、有特性开关兜底、CI 平均反馈时间 ≤ 5 分钟 - 切之前务必先
git pull origin develop，否则新分支起点落后，后续合并时大概率触发“假冲突”（同一行没人改，却提示冲突）
feature 分支命名为什么不能叫 feat-login 或 login-123？
不是语法错，是协作成本高。名字不带作用域和意图，PR 标题、CI 日志、git log --oneline 都会变成谜语。
- 推荐格式：
feature/user-auth-jwt-refresh（模块+功能+关键行为） - 避免纯数字：
feature/123没上下文，查 Jira 还得跳转，CI 失败时定位慢半拍 - 禁止空格和大写：
feature/User Login在某些 CI 环境或脚本里会出路径错误 - 长度控制在 30 字符内：太长的分支名在终端显示会被截断，
git branch列表一眼看不出区别
merge 还是 rebase？什么时候该删本地 feature 分支？
团队统一选一种策略，比“谁对谁错”重要十倍。混合使用会让 git reflog 和 git bisect 失效。
- 用
merge：适合强调“谁在什么时间合了什么”，历史可审计，适合强合规场景（如金融、医疗）；执行git merge --no-ff feature/x强制生成合并提交 - 用
rebase：适合追求线性历史、想用git blame快速定位某行代码作者；但注意：已推送到远程的分支禁止rebase后强制推送（git push --force-with-lease也不行） - 本地分支删除时机：合入成功且远程分支已删后，立即执行
git branch -d feature/x；别留着“以防万一”，它只会干扰git branch -a输出，还可能误切错分支
release 分支要不要保留？
要，但只保留到该版本完成灰度、全量、回滚验证为止。长期挂着 release/v1.2.0 是仓库熵增的典型信号。
- 保留价值：打 patch（比如
hotfix/release-v1.2.0-2）、生成差异包、回溯特定版本构建环境 - 删除时机：确认 v1.2.0 已下线或进入 EOL（End-of-Life），且所有相关 issue / MR / tag 都归档完毕
- 别用 release 分支长期开发：它不是第二个
develop，它的唯一使命是“冻结功能 → 测试 → 发布”，新增需求一律走新的feature/*
最常被忽略的一点：分支策略不是写进 Wiki 就结束的事。它必须嵌进 CI 脚本里——比如在 PR 触发时检查目标分支是否为 develop、分支名是否匹配正则 ^feature\/[a-z0-9-]+$、是否包含 Conventional Commits 格式的提交信息。人会疏忽，机器不会。
