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

Git 热修复 hotfix 分支怎么合并回 master 和 develop 才规范

news 2026/5/15 11:44:49

在标准的 Git Flow 工作流中，hotfix 分支完成修复后，必须同时合并回 master 和 develop 分支，以确保生产环境即时生效且后续开发版本不丢失修复。

先说结论：hotfix 分支源于 master，修复完成后需先合并回 master 发布版本，再合并回 develop 同步修复，最后删除分支。

适合：生产环境出现紧急 Bug 且需要立即修复的场景
先看：当前 develop 分支是否包含未完成的破坏性变更
建议：合并后打上版本标签并推送到远程仓库

命令速用版

git checkout -b hotfix-1.2.1 master
# 进行修复并提交
git add .
git commit -m "Fix critical bug"
# 合并回 master
git checkout master
git merge `--no-ff` hotfix-1.2.1
git tag -a 1.2.1 -m "Release version 1.2.1"
# 推送 master 及标签
git push origin master `--tags`
# 合并回 develop
git checkout develop
git merge `--no-ff` hotfix-1.2.1
# 推送 develop
git push origin develop
# 删除本地及远程分支
git branch -d hotfix-1.2.1
git push origin `--delete` hotfix-1.2.1

为什么要双向合并

master 分支通常代表生产环境的稳定版本，而 develop 分支是下一个版本的开发主线。hotfix 分支是从 master 切出的，只包含修复内容。如果只合并回 master，生产环境问题解决了，但 develop 分支里没有这个修复，下一次发布时旧 Bug 会重新出现。反之，如果只合并回 develop，修复内容会进入下一个版本，但当前生产环境依然存在问题。因此，双向合并是保持版本一致性的必要操作。

分步处理与远程同步

1. 基于 master 创建热修复分支：确保修复起点是生产环境代码，避免带入 develop 中的未完成功能。操作前建议先执行 git pull origin master 确保本地 master 最新。

2. 完成修复并提交：尽量保持提交原子化，只包含必要的修复代码，不要混入重构或新功能。

3. 合并回 master 并打标签：合并时使用 `--no-ff` 保留分支历史，打标签必须添加消息 -m 防止编辑器挂起，方便回滚和版本追踪。

4. 推送远程仓库：合并完成后必须推送 master 分支及标签 git push origin master `--tags`，触发生产环境部署流程。

5. 合并回 develop：将修复合入开发主线，确保后续开发基于已修复的代码。若有冲突需手动解决（见下文）。

6. 清理分支：删除本地和远程 hotfix 分支，保持仓库整洁。

冲突处理实战

在合并回 develop 时，若 develop 分支在 hotfix 期间有较大变动，可能产生冲突。解决步骤如下：

git checkout develop
git merge `--no-ff` hotfix-1.2.1
# 若出现冲突，git status 查看冲突文件
# 手动编辑文件解决冲突标记 <<<<< , ====== , >>>>>
git add <冲突文件>
git commit -m "Resolve merge conflict from hotfix-1.2.1"
git push origin develop