在标准的 Git Flow 工作流中，hotfix 分支完成修复后，必须同时合并回 master 和 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

怎么验证是否生效

1. 查看提交历史：使用 git log `--graph` `--oneline` `--all` 查看提交历史，确认 hotfix 分支的提交同时出现在 master 和 develop 的 lineage 中。

2. 检查标签：执行 git tag -l 检查 master 分支是否有对应的版本标签。

3. 远程验证：在远程仓库页面确认 master 和 develop 分支均已更新，且 hotfix 分支已被删除。

4. 功能验证：在测试环境验证 develop 分支是否包含修复内容，生产环境验证 master 对应版本是否修复 Bug。

常见坑

1. 忘记合并回 develop：这是最容易犯的错误，导致下一个版本发布时修复丢失。

2. 忘记推送远程：本地合并后未 push，导致团队协作失效或 CI/CD 未触发。

3. 标签命令挂起：使用 git tag -a 未加 -m 参数会打开编辑器，导致命令看似卡住。

4. 直接在 master 上修改：严禁直接在 master 分支提交代码，必须通过 hotfix 分支操作。

5. 远程分支残留：合并完成后忘记删除远程 hotfix 分支，导致仓库分支列表杂乱。

参考来源

Vincent Driessen, A successful Git branching model, https://nvie.com/posts/a-successful-git-branching-model/