hotfix分支必须从master（或main）最新提交或对应版本标签创建，修复后必须同时合并到master和develop分支，并使用--no-ff选项保留完整历史。
紧急线上 Bug 必须立刻修复，但又不能把未完成的功能或测试不充分的代码带进生产环境——hotfix 分支就是为此而生的。它不是“绕过流程”的捷径，而是有严格约束的应急通道：只从 master（或 main）拉、只修一个点、必须双向合并、不可跳过测试。
hotfix 分支该从哪条分支创建？
必须从 master（或 main）最新提交创建，更稳妥的做法是直接基于对应版本标签（如 v1.2.0）创建。误从 develop 拉会导致混入未发布功能，上线后可能引发新问题。
- 正确：
git checkout -b hotfix/1.2.1 v1.2.0（推荐，精准锚定出问题的版本） - 次选：
git checkout master && git pull && git checkout -b hotfix/1.2.1 - 错误：
git checkout develop && git checkout -b hotfix/1.2.1（会引入不该上线的代码）
注意：如果项目已将主分支名设为 main，所有涉及 master 的命令需同步替换，否则会报错 error: pathspec 'master' did not match any file(s) known to git。
修复完成后必须合并到哪几个分支？
不是只合回 master 就完事。hotfix 的修改必须同时进入 master 和 develop，否则下次发版时这个修复就丢了。
- 先合入
master：git checkout master && git merge --no-ff hotfix/1.2.1，然后打标签git tag -a v1.2.1 -m "Critical fix" - 再合入
develop：git checkout develop && git merge --no-ff hotfix/1.2.1 - 切勿省略第二步——这是团队协作中最常被跳过的动作，后果是修复在下个大版本里“神秘消失”
如果 develop 上已有大量新提交，合并时可能出现冲突。此时不要强行跳过，应人工比对变更范围，确认修复逻辑是否仍适用。
为什么推荐用 --no-ff 合并？
它强制生成一个合并提交，保留 hotfix 分支的完整上下文。没有它，Git 可能执行快进（fast-forward），导致 hotfix 提交历史被“扁平化”进主线，后续追溯修复来源会困难。
- 有
--no-ff：git log --oneline中能看到独立的Merge branch 'hotfix/1.2.1'提交 - 无
--no-ff：修复提交直接混在主线提交流中，无法区分哪些是热修复、哪些是常规开发 - CI/CD 工具（如 Jenkins、GitLab CI）依赖合并提交识别 hotfix 流水线，缺失它可能导致自动部署失败
hotfix 分支何时可以删除？
只有在两个合并都成功推送且通过验证后，才能删。删早了会导致 develop 分支上缺失修复，删晚了则污染分支列表，干扰日常开发。
- 安全删除时机：
git push origin master develop && git push origin v1.2.1 && git branch -d hotfix/1.2.1 - 远程分支也要清理：
git push origin --delete hotfix/1.2.1 - 别依赖本地
-d就以为远端也删了——很多团队卡在这一步，导致多人重复拉同一个已废弃的 hotfix 分支
真正容易被忽略的，不是怎么拉分支，而是“修复是否真实同步到了所有目标分支”。一次漏合 develop，可能让同一个 Bug 在两周后的正式发版中再次爆发。
