当前位置：首页 > news >正文

如何基于 Git flow 工作流管理发布分支和热修复

news 2026/5/15 19:12:36

Git Flow 工作流适合中大型团队及需要严格版本控制的场景，发布分支用于版本发布前的测试与准备，热修复分支用于生产环境紧急问题的快速修复。相比 git-flow 扩展工具，掌握原生 Git 命令更具通用性，能避免环境依赖问题。

先说结论：发布分支从开发分支切出用于收尾，热修复分支从主分支切出用于救急，修复后都必须合并回主分支和开发分支并打标签。

适合：中大型团队、多协作场景、需要严格版本控制的业务系统
先看：分支基底是否正确（发布基于 develop，热修复基于 master）
建议：修复完成后务必同时合并回 master 和 develop，避免代码不一致

原生 Git 命令实操详解

虽然 git-flow 工具能简化操作，但原生 Git 命令在所有环境中均可用，且更利于理解底层逻辑。以下是基于原生 Git 的标准操作流程。

1. 发布分支（Release）流程

当 develop 分支功能积累足够，准备发布新版本时：

# 1. 基于 develop 创建发布分支
git checkout develop
git pull origin develop
git checkout -b release/1.0.0# 2. 在 release 分支上进行测试、修 Bug（禁止加新功能）
# 提交修改
git add .
git commit -m "fix: release bug fix"# 3. 完成发布：合并到 master 并打标签
git checkout master
git pull origin master
git merge `--no-ff` release/1.0.0
git tag -a v1.0.0 -m "version 1.0.0"
git push origin master `--tags`# 4. 合并回 develop 并清理
git checkout develop
git merge `--no-ff` release/1.0.0
git push origin develop
git branch -d release/1.0.0

2. 热修复分支（Hotfix）流程

当生产环境出现紧急 Bug 时：

# 1. 基于 master 创建热修复分支
git checkout master
git pull origin master
git checkout -b hotfix/1.0.1# 2. 修复问题并提交
git add .
git commit -m "fix: critical production bug"# 3. 完成修复：先合并到 master 并打标签
git checkout master
git merge `--no-ff` hotfix/1.0.1
git tag -a v1.0.1 -m "version 1.0.1"
git push origin master `--tags`# 4. 合并回 develop 并清理
git checkout develop
git merge `--no-ff` hotfix/1.0.1
git push origin develop
git branch -d hotfix/1.0.1

分支合并顺序与冲突处理

合并顺序风险：务必先合并到 master 并打标签，再合并到 develop。若顺序颠倒，可能导致标签指向错误提交，或 develop 包含未验证代码。

冲突解决步骤：合并回 develop 时，因开发进度不同常产生冲突。

执行合并命令时若提示冲突，Git 会暂停合并。
使用 git status 查看冲突文件。
手动编辑文件解决冲突标记（<<<<<<< 等）。
解决后执行 git add <file> 标记解决。
执行 git commit 完成合并（无需加 -m，Git 会自动生成合并信息）。

怎么验证是否生效

检查分支历史：使用 git log `--graph` `--oneline` `--all` 查看分支合并线是否闭合，确认 hotfix 或 release 分支已删除。
验证标签：使用 git tag 确认新版本标签已生成，且指向 master 分支的最新提交。
代码一致性：检查 develop 分支是否包含了热修复的代码，避免后续发布时丢失修复内容。
生产环境：确认 master 分支代码已部署，且线上问题已解决。