git flow核心是确保master永远可部署、develop永远可集成、功能/修复/发布互不污染；所有变更必须经分支→pr→审查→合并，feature须从develop拉，release合并后必须用--no-ff同步develop。
Git Flow 不是“必须用”的银弹，而是中大型项目在多环境、多角色、强发布管控场景下最经得起验证的分支结构。它解决的核心问题是：如何让 master 永远可部署、develop 永远可集成、功能/修复/发布互不污染。
为什么不能直接在 master 上开发或 hotfix？
直接向 master 提交等于绕过所有质量关卡。常见后果包括：
- 测试未覆盖的代码直接上线，引发线上故障
- 多个 hotfix 同时改同一文件，合并时冲突难解，修复被覆盖
-
master上出现 “临时调试代码” 或 “未完成功能开关”，破坏生产稳定性 - 无法基于
master精确打 Tag —— 因为当前 HEAD 可能混着未测完的提交
正确做法是：所有变更必须走分支 → PR → 审查 → 合并流程。哪怕只是改一行日志，也要从 master 拉 hotfix/xxx，修完再合回 master 和 develop。
feature 分支该从 develop 还是 master 拉？
必须从 develop 拉。原因很实际：
-
develop包含了所有已开发但未发布的功能，你的新功能很可能依赖其中的接口或数据结构 - 如果从
master拉，你写的代码会缺失develop中已存在的兼容逻辑，导致合入时大量冲突或运行时异常 - CI 流水线通常只对
feature/*和develop触发构建，从master拉的分支可能不被识别或跳过自动化检查
反例：git checkout -b feature/login master —— 这是危险操作，除非你明确知道这个功能完全独立且无需任何 develop 上的前置改动。
release 分支合并后，为什么必须立即同步 develop？
不是“应该”，而是“必须”。因为 release 分支在测试阶段会产生两类关键变更：
- 测试暴露的 bug 修复（通过
fix/*或直接在release上提交） - 版本号、构建配置、Changelog 等发布专用修改
这些内容若只留在 release 和 master，下次从 develop 拉新 feature 时，就会丢失这些修复和配置，造成“已修复的 Bug 在下一个版本重现”。执行命令应为：
git checkout develop<br>git merge --no-ff release/v1.2.0<br>git push origin develop
注意：必须加 --no-ff，否则 Git 会做 fast-forward 合并，丢失 release 分支的上下文信息，后续难以追溯哪些提交属于本次发布。
保护分支设置容易被忽略的细节
很多团队开了 master 和 develop 的分支保护，却漏掉三个关键点：
- 未启用 “Require pull request reviews before merging” —— 导致 PR 可以无人审查就合入
- 未勾选 “Include administrators” —— 管理员账号仍可绕过规则直推
- 未限制 “Allow force pushes” 为禁用 —— 一旦有人
git push --force，历史会被重写，CI 缓存、Tag 关联全失效
更隐蔽的问题是：有些平台（如旧版 Gitee）默认不阻止删除远程分支。如果 feature 合并后被误删，而本地又没及时 git fetch --prune，开发者可能还在基于一个已不存在的远程分支继续开发。
