Git Flow仅适用于有明确版本周期、需打Tag发布、测试与上线分离的项目；CI/CD频繁部署的后端或前端项目硬套会增加release分支维护成本，易卡在“等测试通过才能合develop”环节。
Git Flow 不是万能模板，用错场景反而拖慢交付节奏。它只适合有明确版本周期、需打 Tag 发布、测试与上线分离的项目；CI/CD 频繁部署的后端服务或前端项目，硬套 Git Flow 会多出 release 分支维护成本，还容易卡在“等测试通过才能合 develop”这一步。
feature 分支必须从 develop 拉，不能从 main 或其他 feature 拉
这是最常踩的坑：有人为图省事直接 git checkout -b feature/login main，结果新功能里混进一堆未验证的旧逻辑，合回 develop 时引发大面积冲突或回归问题。
- 正确做法永远是：
git checkout develop && git pull && git checkout -b feature/login - 开发中要定期同步
develop：git pull origin develop（不要用git merge，避免引入无关提交） - 如果多人共用一个
feature/*分支，务必约定每日 rebase 到最新develop，否则 PR 时 diff 会爆炸
release 分支创建后，禁止新增功能，只修 bug 和调配置
常见错误是把 release/v1.3.0 当成“最后开发窗口”，又塞进一个需求字段或接口调整——这会让测试环境和预发布环境行为不一致，也违背了 release 分支“冻结功能”的设计本意。
- 创建命令：
git checkout -b release/v1.3.0 develop - 只允许提交：
version.txt修改、文档更新、测试发现的 bug 修复 - 一旦测试通过，必须立刻合并到
main并打 tag：git tag v1.3.0，再合并回develop（注意顺序，先main后develop） - 合并后立即删除远程
release/v1.3.0，避免残留分支干扰后续流程
hotfix 分支必须从 main 拉，且修复后要双线合并
线上崩溃了，你急着切 hotfix/login-crash，但忘了它得同时回到 main 和 develop。只合 main 的后果是：下个版本里这个 bug 还在，因为 develop 没同步修复。
- 拉取命令：
git checkout main && git pull && git checkout -b hotfix/login-crash - 修复提交后，先合到
main：git checkout main && git merge --no-ff hotfix/login-crash - 再合到
develop：git checkout develop && git merge --no-ff hotfix/login-crash - 最后删掉本地和远程
hotfix/login-crash分支
真正难的不是记命令，而是每次切分支前问一句：这个变更影响的是哪个环境？是否需要跨分支同步？很多团队崩在流程上，不是不会操作 Git，是没把分支背后的责任边界理清楚。
