main分支必须受保护且仅通过PR合并，所有CI流程绑定PR触发，强制要求1人CR+全部CI通过；feature/hotfix/release前缀是自动化依据，命名须规范；hotfix须同步合并至main和dev；超期未合分支需清理；Conventional Commits为回滚前提。
main分支必须受保护，且只接受PR合并
任何直接向main推送代码的行为，都会破坏可发布性底线。它不是“默认分支”而已，而是生产环境的唯一可信源。
- 所有CI流程必须绑定
main分支的PR触发，而非push触发 - 强制要求至少1人通过Code Review + 所有CI检查通过后才允许合并
- 禁止在
main上执行git merge --ff或git rebase等会丢历史的操作 - 如果团队用Gitee/GitLab，务必开启分支保护规则：禁用force push、禁用直接push、要求status check
feature/、hotfix/、release/前缀不是装饰，是自动化依据
CI/CD脚本、清理机器人、甚至Git hooks，都依赖这些前缀做路由判断。写错前缀=绕过整套流程。
-
feature/user-login-api合法；feature/user_login_api或feature/login不合法——前者下划线破坏工具解析，后者语义模糊无法追溯需求 -
hotfix/db-conn-leak应从main拉出，修复后必须同时合并回main和dev（如有），否则下次发布仍带bug -
release/v2.1.0一旦创建，就应冻结该分支上的新功能提交，只允许cherry-pick已验证的hotfix
分支生命周期比命名更关键，超期未合即风险
一个存活超过14天的feature/xxx分支，大概率已在偏离主线，合并时冲突成本远高于重写。
- 建议在PR模板里强制填写关联需求ID（如
PROJ-123）和预计完成时间 - CI可自动标记：分支创建满7天未更新→发Slack提醒；满14天未合并→加标签
stale并限制push - 删除合并后的远程分支不是“礼貌”，是防止误操作：有人可能基于旧分支继续开发，再推上来就覆盖了主线历史
Conventional Commits不是锦上添花，而是回滚前提
没有规范提交信息，git revert -m 1或git log --grep="feat:"就失去意义。紧急回滚时没人有时间读diff。
- 必须区分
fix和hotfix：前者修测试环境bug，后者专指已上线问题，需同步触发告警通知 -
feat(payment): add Alipay QR code support比add alipay多花5秒，但能让运维快速定位支付模块变更范围 - 禁止出现
update、fix bug、final version这类无上下文提交——它们在git bisect里毫无价值
git branch -r --merged origin/main | grep feature，删掉那些早已没人维护却还挂着的分支，比写一百行正则校验脚本更有效。 
