生产环境紧急修复时，最稳妥的方式是从对应的发布 tag 切出 hotfix 分支，修复验证后再合并回主分支并打新 tag。
先说结论：基于 tag 创建 hotfix 分支能确保修复基线明确，避免混入未测试的新代码，适合线上故障急需止损的场景。
- 适合：生产环境已打 tag 版本出现 Bug，且主分支已有未发布变更的情况
- 先看：确认当前线上运行的具体 commit 或 tag 版本，避免修错分支
- 建议：修复完成后务必通过 Pull Request 合并回主分支，确保经过 CI 验证与代码审查
命令速用版
# 同步最新 tag 列表
git fetch `--tags`# 基于 tag 创建 hotfix 分支
git checkout -b hotfix/v1.0.1 tags/v1.0.0# 提交修复
git commit -m "fix: emergency fix for production issue"# 推送到远程 hotfix 分支
git push origin hotfix/v1.0.1# 后续需在代码平台创建 PR 合并至 main，审核通过后打新 tag
git tag v1.0.1
git push origin v1.0.1操作流程详解
1. 确认线上版本：通过日志或部署系统找到当前运行的 tag 或 commit hash，不要凭记忆操作。执行 git fetch `--tags` 确保本地 tag 列表是最新的。
2. 创建分支：本地基于该 tag 创建 hotfix 分支，命令如 git checkout -b hotfix/xxx tags/v1.0.0，不要直接在 tag 上修改。
3. 提交修复：最小化修改，只改故障相关代码，提交信息注明紧急修复原因和关联问题单号。
4. 合并回主：推送 hotfix 分支后，在代码托管平台创建 Pull Request 合并至 main/master。确保经过 CI 流水线验证和 Code Review，避免直接 push 绕过保护策略。
5. 发布新 tag：合并完成后，基于主分支打新 tag 并推送，触发正式部署流程。
合并冲突处理
若主分支在此期间有更新，合并 hotfix 时可能产生冲突。切勿强制推送，应按以下步骤解决：
# 切换至 hotfix 分支
git checkout hotfix/v1.0.1# 尝试合并主分支代码
git merge main# 手动解决冲突文件中标记的 <<<<< 和 >>>>> 内容# 提交解决后的代码
git add .
git commit -m "resolve conflict with main"# 再次推送
git push origin hotfix/v1.0.1紧急回滚方案
若修复上线后引发新问题，需立即回滚：
- 代码回滚：使用
git revert生成反向提交，比重置历史更安全。git revert <commit-hash> - Tag 处理：若 tag 刚创建未广泛使用，可删除后重新打 tag。
git tag -d v1.0.1 && git push origin :refs/tags/v1.0.1 - 部署回滚：优先在 CI/CD 平台执行上一版本的重新部署，而非仅依赖 Git 操作。
验证与检查
检查 CI/CD 流水线是否通过，确认新 tag 已推送到远程仓库。登录生产环境查看版本号是否更新，观察错误日志是否不再出现异常堆栈。如果有监控告警，确认告警状态是否恢复。
常见坑与注意事项
1. 忘记合并回主分支：导致下次发布时修复丢失，问题重现，这是最容易犯的错误。
2. 基于错误分支修复：基于 main 而不是 tag，带入未测试代码，引发二次故障。
3. 权限不足：紧急情况下确保有推送 tag 和受保护分支的权限，提前配置好 SSH 密钥或访问令牌。
4. 本地未同步：操作前务必 git fetch `--tags`，确保本地 tag 列表是最新的，避免基于旧版本创建分支。
5. 绕过代码审查：紧急修复也应尽量保留最小限度的 Review，避免单人决策导致逻辑漏洞。
原文链接：https://www.zjcp.cc/ask/11319.html