中小团队应从功能分支工作流起步，仅保留main和feature/*两个核心分支，main受保护、禁止直推，feature命名统一为feature/模块-简述，hotfix和release分支按需临时创建并严格同步，避免过度设计拖慢发布节奏。
怎么选分支模型：别直接抄 GitFlow
中小团队直接套用完整 GitFlow 容易卡在 release/* 和 hotfix/* 分支的维护上，反而拖慢发布节奏。实际观察到的高频问题是：release 分支没人及时合入 develop，hotfix 合并后漏掉 develop 同步，导致下个版本重复修复。
推荐从「功能分支工作流」起步，只保留 main 和 feature/* 两个核心分支，其他按需扩展：
-
main必须受保护，禁止直接 push，只允许通过 PR 合并 -
feature/*命名统一用feature/模块-简述（如feature/auth-login），避免feat/或feature_等混用 - 当出现线上紧急问题时，才临时切
hotfix/*，且必须同时合并回main和develop（如果用了develop） - 没有持续交付能力前，先别建
release/*—— 它本质是为灰度、多环境验证服务的，不是“看起来专业”的装饰
分支命名和生命周期怎么管：别让分支变成仓库垃圾
分支不清理，三个月后 git branch -a 输出会超过 50 行，PR 列表里一堆 stale 分支干扰判断。命名不规范，feature/login 和 login-feature 并存，CI 脚本匹配规则就失效。
执行三条硬约束：
- 所有远程分支创建后 7 天内必须合并或删除，CI 可加定时 job 自动提醒（脚本可用
git for-each-ref --sort=-committerdate --format='%(refname:short) %(committerdate:iso8601)' refs/heads/feature/* | head -n 10查最老未合并分支） -
feature/分支名中禁用空格、大写字母、下划线，只允许小写字母、短横线、数字（如feature/payment-v2✅，feature/PaymentV2❌） - 禁止复用已删除分支名 ——
feature/user-profile合并后删掉，就不能再建同名分支，否则 git log 会串历史
合并前必须同步最新主干：为什么你总在解决同一处冲突
很多人在 feature/login 上开发一周，最后 git merge main 时发现 20+ 冲突，其实是因为中间 main 已被别人合入了 user-service 模块重构。这不是运气差，是没做同步。
标准动作只有两步，但必须每次提交前执行：
- 切换回
main：git checkout main && git pull origin main - 变基到最新：
git checkout feature/login && git rebase main（注意：仅限本地未推送分支；已推远程的用git merge main更安全）
rebase 后如果出现冲突，解决完要 git add . && git rebase --continue，别用 git commit —— 那会生成多余提交，破坏线性历史。
PR 描述和审查要点：别把 PR 当“通知”，要当“交接文档”
很多 PR 标题写“fix bug”，描述空白， reviewer 只能靠猜逻辑。更糟的是，有人把数据库迁移、接口变更、前端适配全塞进一个 PR，结果测一半发现后端改了字段类型，前端白忙。
强制要求每份 PR 至少包含：
- 标题明确类型和范围：
fix(auth): 修复 JWT 过期时间校验逻辑 - 描述区填三行：「改了什么」+「为什么这么改」+「如何验证」（例如：“将
exp字段校验从 `>=` 改为 `>`；原逻辑导致刚过期 token 仍被接受；本地启服务调/login返回 401 即可复现”） - 关联 issue（如有）：
Closes #123，让 GitHub 自动关闭 issue - 标记是否含 breaking change：在描述末尾加
⚠️ BREAKING: 修改了 UserDTO 的 id 类型为 string
审查人不点 Approve 前，CI 不允许合并 —— 这条规则比任何文档都管用。
实际落地最难的不是设计，是坚持每天删掉已合并的本地分支、坚持在 PR 描述里写清楚「如何验证」、坚持不让任何人绕过 PR 直推 main。这些动作不酷，但它们才是规范真正生效的边界。
