feature分支必须从develop拉，因develop是唯一经CI验证的集成基线；从master拉会跳过在研逻辑导致合并冲突，从其他feature拉则引入未合入临时状态，违背单一意图原则。
大型团队用 Git，光靠 git checkout 和 git push 不行，必须靠分支策略兜底 —— 否则每天都在救火。
feature 分支为什么必须从 develop 拉，不能从 master 或其他 feature 拉？
这是最常被跳过的一步，但直接决定后续是否频繁冲突、PR 是否总被拒。
-
develop是唯一可信的“集成基线”，它已包含所有已验证功能，且经过 CI 流水线检查 - 若从
master拉feature，等于跳过所有正在开发中的逻辑，合并回develop时大概率触发both modified冲突，尤其在共享配置、DTO、DAO 层 - 若从另一个
feature拉，相当于把未合入的临时状态作为起点，违反“每个分支只承载一个明确意图”的原则，Code Review 无法聚焦 - CI 系统通常只对
develop和release/*做全量测试，从非受控分支拉出的代码，本地跑通 ≠ 远程能过流水线
hotfix 分支合并后，为什么必须同时合入 master 和 develop（以及当前 release）？
漏掉任意一个，就会造成“线上有修复、开发环境没修复、UAT 环境还在复现 Bug”这种三头不一致局面。
- 合入
master：保证生产环境打标签发布时包含该修复 - 合入
develop：防止同一问题在新功能开发中重复出现（比如修复了空指针，但develop里还有类似写法） - 合入当前
release/*：如果 UAT 正在验证即将上线的版本，这个 hotfix 必须进本次发布，否则上线即带已知缺陷 - 注意顺序：
hotfix先合master→ 打vX.Y.Z+1标签 → 再合develop和release/*；反向操作会导致develop引入未验证的生产代码
release 分支创建后，为什么禁止新增功能，只允许修阻断性 Bug？
不是“建议”，而是硬性冻结 —— 这个阶段任何功能变更都会破坏测试结论的可信度。
- 测试同学基于
release/1.2.0提交全部用例，若中途加入新逻辑，回归范围扩大，用例需重写，时间不可控 - 运维部署脚本、灰度策略、DB 变更脚本都按该分支快照生成，新增功能可能引入未评估的依赖或配置项
- CI 流水线在此分支上会关闭单元测试覆盖率强制门禁，但开启接口级冒烟测试和性能基线比对 —— 新功能没走完这些流程就上线，风险极高
- 若真有紧急需求要插队，正确做法是：暂停当前
release，切出新release/1.2.1，把原release/1.2.0降级为内部预发分支
为什么 feature 分支合并后必须立即删除远程分支？
不是为了“整洁”，而是避免误操作和权限扩散。
- 远程
feature分支残留，可能被其他人误git checkout后继续提交，导致“已合代码又被改”的脏历史 - 某些 CI 工具（如 Jenkins Pipeline）会扫描所有远程分支触发构建，大量闲置
feature分支会浪费构建资源、掩盖真实失败 - GitLab/GitHub 的分支保护规则默认只对
main、develop生效，feature/*无保护，一旦有人force push，历史就不可逆丢失 - 删除命令就是
git push origin --delete feature/login，别等 PR 关闭后手动点网页删 —— 脚本化清理才可靠
真正难的不是记住规则，而是在需求压着、上线倒计时、测试反复提 Bug 的时候，依然坚持先切分支、再同步基线、再提交、再 PR —— 那些省下的 30 秒，最后会变成 2 小时的冲突解决和回滚验证。
