feature分支必须合入develop而非master，hotfix需双线合并至master和develop，bugfix仅进develop；所有合并须经对应环境验证。
feature 分支必须先合入 develop，不能直连 master
feature 分支的归宿是 develop，不是 master。哪怕你开发的是“马上要上线”的功能，只要它还没走完测试和预发布流程，就绝不能跳过 develop 直接合并到 master。否则会破坏流水线稳定性，导致测试遗漏、环境不一致、甚至线上事故。
常见错误现象：git merge feature/login --no-ff 在 master 上执行成功，但后续发现登录页样式错乱——因为该功能依赖的 UI 组件更新只提交在 develop 里，master 并未同步。
- 所有
feature/xxx分支都应基于最新develop创建（git checkout -b feature/xxx origin/develop） - 合并前必须先
git pull origin develop更新本地develop，再git merge --squash feature/xxx - 提交信息强制包含
feat:前缀，例如feat: add OAuth2 login flow
hotfix 分支要双线合并：master → develop → feature（如需）
hotfix 分支从 master 拉出，修复后必须同时合并回 master 和 develop。漏掉 develop 是高频失误，会导致下个迭代把 bug 带回去。
典型场景：线上支付回调超时，你从 master 拉出 hotfix/payment-timeout-20260723，修完后：
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
- 先切到
master，git merge hotfix/payment-timeout-20260723，打 tag 推送 - 再切到
develop，git merge hotfix/payment-timeout-20260723—— 这步不能省 - 如果当前有正在开发的
feature/xxx分支且已落后于develop，需手动git rebase develop或git merge develop同步修复
bugfix 分支只进 develop，不进 master，除非触发 hotfix 流程
bugfix/xxx 和 hotfix/xxx 本质不同：bugfix 针对的是测试或预发环境发现的问题，修复后走常规 PR 合入 develop 即可；只有当问题已在线上发生、影响用户、需立即止损时，才升级为 hotfix。
容易踩的坑：
- 把测试环境发现的空指针误当成 hotfix，拉了
hotfix/xxx分支，结果合并到master引发新问题 - 在
bugfix/xxx中修改了不该动的核心逻辑（比如重写了鉴权中间件），却没做充分回归测试 - 修复提交信息写成
fix: xxx，但实际代码改动涉及多个模块，缺乏上下文说明
合并顺序冲突时，以时间戳 + 环境状态为准，不看分支名
别信分支名里的“v2.1”或“urgent”，真正决定合并优先级的是：哪个分支所对应的功能/修复已经通过对应环境验证。比如：
-
feature/order-v2已在测试环境验收通过，而hotfix/db-connection-leak还卡在本地调试 —— 那么前者可以先进develop，后者等验证完再进 - 两个
hotfix同时提交，hotfix/api-rate-limit-20260723的 PR 已被 QA 标记“✅ verified in staging”，而另一个还在“❌ pending test” —— 前者优先合并
最常被忽略的一点：合并操作本身不保证正确性，git merge 成功只是第一步；真正的分水岭在「是否经过对应环境的最小可行验证」。没跑过 staging 的 hotfix，和没跑过 test 的 feature，都不该进入下一环节。
