main是主分支，develop是长期存在的集成缓冲区；若版本周期长或需并行维护多版本，则必须设develop，且仅允许CI验证后的PR合并。
main 和 develop 分支到底谁该当“主分支”
现在绝大多数新项目默认用 main 代替 master，但要不要再设一个长期存在的 develop 分支，得看团队节奏。如果每周都上线、CI/CD 流水线完备、每个 feature/* 分支都自带测试和文档，那直接基于 main 做 GitHub Flow 就够用；但如果版本周期长（比如每季度发一版）、需要并行维护多个线上版本（如 v1.2.x 和 v2.0.x 同时修 bug），就必须引入 develop 作为集成缓冲区——它不是“开发中”，而是“已验证可合入”的待发布候选集。
常见错误是把 develop 当成“随便提交”的沙盒：有人直接 git push origin develop 而不走 PR，结果测试未覆盖的代码污染了集成基线。正确做法是只允许通过 CI 验证后的 PR 合并到 develop，且每次合并后触发一次全量回归测试。
release 分支怎么开才不踩坑
release/* 不是“准备发布的分支”，而是“已冻结、只允许修复 bug 的发布候选分支”。它必须从 develop（或某个稳定 commit）切出，不能从 feature/* 直接拉。
- 开分支前先确认
develop已通过所有自动化检查（单元测试覆盖率 ≥80%、E2E 全通、安全扫描无高危） - 分支名建议用
release/v2.1.0，而不是release/202607—— 版本号能直接对应 tag，避免后期对不上 - 测试期间发现 bug，必须在
release/v2.1.0上修复并提交，再 cherry-pick 到develop（不是反向 merge），否则develop会漏掉这个补丁 - 上线后立即执行两件事：
git merge --ff-only release/v2.1.0到main，然后git tag v2.1.0；接着git merge --ff-only release/v2.1.0回develop，最后删掉远程release/v2.1.0
hotfix 分支为什么必须从 tag 而不是 main 拉
线上紧急问题往往发生在旧版本（比如 v1.2.3），而此时 main 可能已是 v2.1.0 的代码。若直接从 main 拉 hotfix，修复后合回去会把 v2.1.0 的大量新逻辑一起带进 v1.2.3 环境，引发不可预知行为。
正确操作是：
- 先查出出问题的版本对应的 tag：
git tag --points-at origin/main或翻 release 记录 - 从该 tag 创建分支：
git checkout -b hotfix/v1.2.4-security-patch v1.2.3 - 修复、测试、提交后，
git push origin hotfix/v1.2.4-security-patch，走 PR 合并到main和develop - 合并后立刻打新 tag：
git tag v1.2.4，并推送到远端
注意：如果项目同时维护多个 release 分支（如 release/1.2.x 和 release/2.0.x），hotfix 还需 cherry-pick 到对应 release 分支，不能只靠 merge。
feature 分支命名和生命周期管理
feature/* 是最易失控的分支类型。命名不规范会导致 PR 无法关联 issue、CI 规则失效、清理脚本失灵。
强制约定：
- 格式必须为
feature/[JIRA-123]-login-flow或feature/github#45-login-refactor，斜杠后第一段是唯一追踪 ID - 禁止使用模糊词：
feature/new-ui、feature/fix-bug都算违规 - 本地开发完成但未提 PR 前，至少每天
git pull origin develop一次，避免最后合并时出现几十个冲突文件 - PR 关闭后 3 天内，远程分支必须删除；CI 可配自动清理规则：
if [ "$GITHUB_EVENT_NAME" = "pull_request" ] && [ "$GITHUB_EVENT_ACTION" = "closed" ]; then git push origin --delete $BRANCH_NAME; fi
真正难的是让所有人坚持——哪怕只是改一行 CSS，也要开分支、写描述、走流程。松动一次，分支就多一个没人认领的幽灵。
