git flow 不是开箱即用的“自动模式”，它依赖严格初始化、分支语义闭环和手动补全动作；跳过任何一环，git flow release finish 打的 v1.2.0 tag 就可能在 ci 里查不到。

Git Flow 不是开箱即用的“自动模式”，它依赖严格初始化、分支语义闭环和手动补全动作；跳过任何一环，git flow release finish 打的 v1.2.0 Tag 就可能在 CI 里查不到。

git flow init 必须先有正式 Tag 才能跑

很多人执行 git flow init -d 后发现 develop 分支像从零开始——因为远程 main 没打过第一个正式 Tag（比如 v1.0.0），git flow init 就会默认新建空 develop，导致后续所有 release 和 hotfix 的基线错位。

• 检查远程 main 是否已有 Tag：git ls-remote --tags origin | grep -v '\^{}$'
• 若无，先切到 main，打首个 Tag：git tag v1.0.0 && git push origin v1.0.0
• 再运行 git flow init -d，完成后立刻验证 .git/config 中 [gitflow "branch"] 段是否把 master 映射为实际远程主干名（如 main）
• 最后手动让 develop 继承历史：git checkout develop && git merge main --no-ff -m "chore: init develop from main"

feature 分支必须用 finish，不能手工 merge

手工执行 git checkout develop && git merge feature/login 看似等价，但漏掉 --no-ff 会导致分支拓扑丢失，CI 工具无法识别该提交来自哪个功能分支，也破坏了 Git Flow 的语义闭环。

Git Changelog Generator

使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……

下载

• git flow feature finish login 会原子化完成三件事：切回 develop、--no-ff 合并、删除本地 feature/login
• 如果团队用 GitHub/GitLab，建议禁用 feature/* 的直接 push 权限，只允许通过 git flow feature publish 或约定命名空间推送
• 远程 feature 分支不是必需的；若需协作开发，应明确约定谁负责 finish，避免多人重复操作

release finish 后必须手动推 Tag

git flow release finish 1.2.0 默认只推 main 和 develop 分支，v1.2.0 Tag 留在本地——这是最常被忽略的一步，导致 CI 脚本中 git describe --tags 查不到最新版本。

• 补推命令是：git push origin --tags
• 长期解法：设全局配置 git config --global push.followTags true，此后 git push 自动包含轻量 Tag
• 注意：某些 CI（如 Jenkins Pipeline）依赖轻量 Tag，但 git flow release finish 默认打的是附注 Tag；如需轻量 Tag，得改用 git tag -a 手动打，或调整脚本

hotfix 必须双向合并，且起点只能是 main

热修复分支必须从 main 拉出，否则修复无法精准对应线上版本；合并时若只推回 main 而漏掉 develop，下个版本就会丢掉这个修复。

• 正确流程：git flow hotfix start critical-bug → 修 bug → git flow hotfix finish critical-bug
• 该命令会自动合并到 main 和 develop，并打 Tag（如 v1.2.1）
• 若因权限限制无法自动合并 develop，务必人工补：git checkout develop && git merge hotfix/critical-bug --no-ff
• 严禁从 develop 或其他分支拉 hotfix——这会让修复偏离真实线上状态

Git Flow 的复杂点不在命令本身，而在每个分支背后承载的发布语义：Tag 是谁打的、从哪打的、推没推，决定了整个流程是否可信。一个没推的 Tag，比没写的代码更危险。