hotfix分支是Git中专用于紧急修复生产环境严重缺陷的临时分支，必须从master/main分支拉取，修复后同时合并回master和develop分支，并打新tag。
什么是 hotfix 分支，不是 bug 分支
Git 本身没有叫 bug 的内置分支类型，你看到的“Bug 分支”实际是团队约定俗成的说法，标准术语是 hotfix 分支。它专用于紧急修复已上线（main 或 master）代码中的严重缺陷，目标是快速验证、合入、发布，**不经过开发/测试分支中转**。
关键区别在于起点和流向：hotfix 必须从线上稳定分支（如 main）拉出，修复后直接合并回 main 和 develop（或当前开发主线），避免遗漏补丁。
- 错误做法：从
feature/login拉分支修线上 Bug → 补丁只在功能分支里，线上依然崩 - 正确做法：
git checkout -b hotfix/payment-fail main→ 修完先git merge --no-ff hotfix/payment-fail到main，再git merge --no-ff hotfix/payment-fail到develop - 漏掉
develop合并会导致下次发版又带这个 Bug
git checkout -b 和 git switch -c 在 hotfix 场景下的选择
创建 hotfix 分支时，必须确保基于最新线上提交，所以第一步永远是同步远程 main：
git fetch origin main<br>git checkout origin/main -b hotfix/db-null
这里不用 git switch -c，因为 git switch 默认基于当前 HEAD 创建，而你很可能不在 main 上；用 git checkout origin/main -b 能强制从远程最新快照起始，避免本地 main 落后引入旧问题。
-
git checkout -b兼容所有 Git 版本，适合 CI/CD 脚本或老旧环境 -
git switch -c更语义化，但要求 Git ≥2.23，且不能直接指定远程 ref（需先git switch main && git pull） - 生产环境建议统一用
git checkout origin/main -b hotfix/xxx，省去切换+拉取两步
合并 hotfix 时为什么总遇到 “Already up to date” 却没生效
这是最常踩的坑：你以为合并成功了，但线上版本重启后 Bug 还在。根本原因是合并操作没推送到远程，或者没打 tag。
- 执行
git merge hotfix/db-null只更新了本地main分支指针，git push origin main才真正发布 - 如果用了
--no-ff，合并会产生新 commit，必须 push；如果用了 fast-forward（默认），main指针前移，仍需git push - 线上部署通常依赖 tag（如
v1.2.3），hotfix合并后要立即git tag -a v1.2.4 -m "fix: payment null pointer"并git push origin v1.2.4 - 漏 push 或漏 tag → CI/CD 拉的还是旧 commit，修复等于白做
删除 hotfix 分支的时机与风险
hotfix 分支不是用完就删——必须等它所含的 commit 已被两个目标分支（main 和 develop）都收录后才能删。
检查方法：git merge-base hotfix/db-null main 和 git merge-base hotfix/db-null develop 返回的 commit ID 都应等于 hotfix/db-null 的最新 commit（即已完全合入）。
- 过早删分支：
git branch -d hotfix/db-null报错 “not fully merged”，这是保护机制，别强行用-D - 删完才发现
develop没合并？只能靠git cherry-pick补救，但会丢失原始 author 和时间戳 - 推荐流程：合并 → push → tag →
git branch -d hotfix/db-null→git push origin --delete hotfix/db-null
真正容易被忽略的是：hotfix 的 commit message 必须包含可追溯的上下文（比如 Jira ID、影响范围），否则半年后没人记得这个修复到底解决了什么。
