main分支必须始终可部署，选择分支模型需匹配团队发布节奏：月/双周发布宜用git flow，高频ci/cd宜用trunk-based development；小团队应避免过度工程化；分支命名须规范、可grep；合并前须fetch、rebase、本地测试；保护main靠自动化检查而非单纯禁止push。
main 分支必须始终可部署，否则团队协作的节奏会从第一天起就失控。
怎么选分支模型：看发布节奏，不看教程推荐
Git Flow 不是银弹，Trunk-Based Development（TBD）也不是万能解药。关键在匹配团队真实节奏：
- 如果版本按月/双周发布，且有明确测试、预发、上线阶段，
develop+feature/*+release/*是合理选择 - 如果每天多次 CI/CD 自动部署，且功能通过 Feature Flag 控制开关，直接用
main作为唯一长期分支更轻量 - 5人以下小团队，强行上 Git Flow 反而增加 PR 审核负担和合并等待时间
一个常见误判是：看到“大厂用 Git Flow”就照搬。但大厂往往配套了自动化 cherry-pick、自动 tag 推送、分支生命周期监控等工具链——没这些，光靠命名规范撑不住。
分支命名不是风格问题，是 grep 可维护性问题
你写的分支名，要能被 git branch -a | grep "feature" 或 git for-each-ref --format="%(refname:short)" refs/heads/ | grep hotfix 精准筛选出来。这意味着：
- 禁止用空格、下划线、中文或特殊符号：
feature/user_login比feature/user login更可靠 - 统一前缀比“语义清晰”更重要：
fix/和hotfix/必须区分用途——前者修开发环境 Bug，后者只用于线上紧急回滚 -
release/v1.2.0中的v前缀不能省，否则git tag和git branch列表容易混淆
很多团队踩坑在“临时分支不清理”，结果 git branch -a 输出上百行，真正有用的分支反而被淹没。
合并前必须做三件事：fetch、rebase、本地测试
直接 git merge feature/x 再推 main 是高冲突率的根源。正确顺序是：
- 先
git fetch origin拉取远程最新状态，确认origin/main是否已更新 - 在
feature/x分支上执行git rebase origin/main，把你的提交“重放”到最新主干上（注意：仅限未推送的本地分支） - 本地跑通所有测试（至少包括单元测试 + 关键路径集成），再切回
main执行git merge --ff-only feature/x
跳过 rebase 直接 merge，会导致历史中出现大量无意义的“merge commit”，后续 git bisect 或 git blame 会指向错误提交；用 --no-ff 强制生成 merge 提交，在高频协作中只会让日志越来越难读。
保护 main 的真正手段不是“禁止 push”，而是“无法绕过检查”
平台级分支保护（如 Gitee/GitHub 的 branch protection rules）只是第一层。真正起效的是配套机制：
- CI 流水线必须在 PR 合并前完成：单元测试 + 静态扫描 + 构建打包，任一失败则阻断合并
- PR 描述模板强制填写：
What changed、How to test、Related issue，缺一不可 - 删除已合并分支的脚本应设为定时任务（例如每天凌晨执行
git branch --merged main | grep -v "^\*" | grep -v "main" | xargs -r git branch -d），避免分支堆积
最常被忽略的一点：分支保护规则里开启 “Require linear history” 后，git merge --no-ff 就会失败——但很多团队配置了却不知道为什么 PR 总被拒绝，最后干脆关掉该选项，等于白设。
