Git Flow需正确初始化、严格分支管理及完整合并策略：必须先打正式Tag再init，确保develop继承main历史；feature须用finish而非手工合并；release需手动push tags；hotfix必须双向合并至main和develop。
Git Flow 不是“开箱即用”的默认工作流，它需要明确初始化、严格分支角色划分和手动或工具辅助的合并策略；直接在已有仓库上套用 git flow init 而不清理历史或统一命名，大概率导致分支混乱、Tag 错位、hotfix 合并遗漏。
git flow init 初始化必须做对这三件事
很多团队跳过初始化或只执行一次 git flow init 就以为万事大吉，结果 develop 分支没真正承载开发历史，main 分支没打过 Tag，后续所有 release/hotfix 都会失准。
- 先确认远程已有
main（或master）且其 HEAD 已打过首个正式 Tag（如v1.0.0），否则git flow init会默认从空提交建 develop，造成历史断裂 - 运行
git flow init -d（使用默认配置）后，立刻检查 .git/config 中的[gitflow "branch"]段是否将master映射为main（若远程主干叫main但本地配置仍写master，后续git flow release finish会推错分支） - 初始化完成后，手动执行一次
git checkout develop && git merge main --no-ff -m "chore: init develop from main"，确保 develop 包含全部生产历史，而非从零开始
feature 分支不能直推到远程再合并
看似省事的 git push origin feature/login + PR 合并，绕过了 Git Flow 的语义闭环：feature 分支本应只存在于本地或临时远端，且必须通过 git flow feature finish 完成合并、删除、切回 develop 三步原子操作。
- 直接 push feature 分支会导致 CI/CD 环境误触发构建（尤其当 CI 配置了
**/feature/**触发规则） -
git flow feature finish会自动执行git checkout develop && git merge --no-ff feature/login && git branch -d feature/login，而手工 merge 容易漏掉--no-ff，丢失分支拓扑信息 - 若团队用 GitHub/GitLab，建议禁用
feature/*的直接 push 权限，只允许通过git flow feature publish（需额外配置）或内部约定的临时远端命名空间推送
release finish 后 Tag 不生效的常见原因
git flow release finish 默认会在 merge 到 main 后打 Tag，但你 push 后在 CI 或部署脚本里查不到该 Tag，通常不是命令失败，而是推送动作不完整。
- 它只推送
main和develop分支，不会自动推送 Tag —— 必须额外执行git push origin --tags - 如果本地
git config --global push.followTags true未开启，每次release finish后都得手动补推 Tag - 某些 CI 工具（如 Jenkins Pipeline）读取
git describe --tags时依赖轻量 Tag，但git flow默认打的是附注 Tag（annotated），需确认部署脚本是否兼容
hotfix 分支修复后必须双向合并
线上 bug 修复最常犯的错：从 main 拉出 hotfix/db-timeout，修完只合回 main，忘了同步到 develop —— 导致下个版本又出现同一问题。
-
git flow hotfix finish hotfix/db-timeout会自动合并到main和develop，但前提是执行前develop是最新状态（否则 merge 产生冲突，工具可能静默失败） - 若
develop当前有未完成的 feature 正在开发，hotfix finish合并进develop可能引入不稳定变更；此时应先git checkout develop && git pull，再运行 finish - 极少数情况需跳过自动合并（如 hotfix 仅适配旧版逻辑），可改用
git checkout main && git merge hotfix/db-timeout && git checkout develop && git cherry-pick <commit-hash>，但必须人工记录 cherry-pick 提交，避免重复
Git Flow 的复杂性不在命令本身，而在每个分支动作背后隐含的发布语义和协作契约；一个没打 Tag 的 release、一个没合回 develop 的 hotfix、一个命名不带斜杠的 feature 分支，都会让整个流程在三个月后变成“谁也说不清这个 commit 到底属于哪个版本”的现场。
