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，都依赖这些前缀做路由判断。写错前缀=绕过整套流程。

GitHub 智能代码审查与 CI/CD 自动化

GitHub 智能代码审查与 CI/CD 自动化工作流。收到 PR 或代码提交时，自动进行 AI 代码审查（bug/安全/逻辑），并根据审查结果智能生成或推荐 GitHub Actions 工作流。触发词：代码审查、review PR、生成 CI/CD、GitHub Actions。

下载

• 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里毫无价值

分支命名本身不难，难的是让所有人持续遵守。最容易被忽略的不是格式，而是「分支存在本身是否还有业务价值」——每天早上花30秒看一眼git branch -r --merged origin/main | grep feature，删掉那些早已没人维护却还挂着的分支，比写一百行正则校验脚本更有效。