Git分支管理需适配团队节奏：feature分支应从develop切出（非main），命名推荐feature/模块-功能-行为格式，合并策略须统一，release分支仅短期保留，且分支规则须嵌入CI自动化校验。

在Git分支管理这件事上，其实不存在什么“标准答案”，真正重要的是找到“适配当前团队节奏的答案”。盲目套用经典的Git Flow，或者图省事全用一根main分支，往往会在两三个月后暴露出问题：合并冲突集中爆发、发布回滚变得棘手，新人更是对着代码库望而却步，不敢下手。

feature 分支该从哪个分支切？

对于绝大多数项目而言，答案是从develop（或者叫next）分支切出来，而不是main。原因很简单：main分支代表的是生产就绪状态，那些功能还没测完、CI流程没过、文档也没跟上的代码，不应该去污染它。

• 例外情况：紧急的线上热修复（hotfix）必须从main分支切出，修复完成后需要同时合并回main和develop分支。
• 单主干策略：如果团队没有设置develop分支，并且坚持采用Trunk-Based Development（单主干开发），那就只能从main切了。但这有个前提：所有提交都必须附带自动化测试，要有特性开关兜底，并且CI的平均反馈时间最好控制在5分钟以内。
• 关键一步：切分支之前，务必先执行git pull origin develop，确保起点是最新的。否则，新分支的起点落后，后续合并时大概率会触发“假冲突”——明明同一行代码没人改动，Git却提示冲突。

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 分支？

比起争论“merge和rebase谁对谁错”，团队统一选择其中一种策略，重要十倍。混合使用会导致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不删除，是代码仓库“熵增”（混乱度增加）的典型信号。

• 保留价值：用于打补丁（例如hotfix/release-v1.2.0-2）、生成版本差异包、或者回溯特定版本的构建环境。
• 删除时机：确认v1.2.0版本已经完全下线或进入生命周期结束（EOL）阶段，并且所有相关的issue、合并请求（MR）、标签（tag）都已归档完毕。
• 明确界限：千万别把release分支当成第二个develop来长期开发新功能。它的唯一使命是“冻结功能 → 测试 → 发布”，任何新增需求都应该走新的feature/*分支流程。

最后，也是最容易被忽略的一点：分支策略绝不是写进团队Wiki文档就万事大吉了。它必须嵌入到CI/CD的自动化脚本里——例如，在提PR时自动检查目标分支是否为develop，分支命名是否匹配^feature\/[a-z0-9-]+$这样的正则规则，提交信息是否符合Conventional Commits格式。人会疏忽，但机器不会。让自动化流程来守护规则，这才是确保策略持续落地的关键。