Git Flow在小团队中拖慢交付，因其分支过多（develop、feature、release、hotfix）导致合并冲突频发、PR堆积、环境混乱；应简化为main+短生命周期feature分支模型，辅以CI强制校验、语义化标签和权限管控。
为什么 Git Flow 在小团队里反而拖慢交付
中小型团队用标准 Git Flow 容易卡在合并冲突、PR 堆积、环境混乱上。不是流程不对，而是分支太多（develop、feature/xxx、release/1.2、hotfix/xxx）导致协作成本远超收益。真正需要的不是“规范”，而是“能跑通、不扯皮、出问题能快速回滚”的最小可行分支模型。
用 main + short-lived feature 分支就够了
把 main 当作可部署的稳定线，所有功能开发都从 main 拉出短生命周期的 feature/xxx 分支（命名统一用 feature/login-ui 这种小写+短横格式），合并后立刻删掉。不设 develop，不保留长期分支。
- 开发完必须跑通 CI（至少含单元测试 + 构建），否则不准提 PR
- PR 描述里明确写清影响范围（比如“修改了
auth.service.ts的 token 刷新逻辑”），不写“修复 bug”这种模糊描述 - 合并前强制要求至少 1 人 approve，但审批人必须是代码直接相关模块的协作者，不是“随便找个人点个对勾”
-
main上禁止 force push，CI 失败的 commit 不允许跳过检查直接合入
hotfix 怎么处理才不破坏节奏
线上出问题要修，但又不想拉出独立 hotfix/xxx 分支再走一遍完整流程？直接从 main 拉分支，修完立即合并回 main，然后打带版本号的 tag（如 v1.2.1）。不需要同步到其他分支——因为没其他长期分支。
Git Hub Projects V2
下载
使用 gh project CLI 管理 GitHub Projects v2。在代理需要列出待办事项、设置项目字段（如状态、迭代、优先级等）时使用此技能。
- 修复 commit 必须带
[hotfix]前缀，方便后续用git log --grep="[hotfix]"快速追溯 - 如果修复涉及多个文件，优先只改最小必要集；不要趁机“顺手重构”
- 上线后立刻在内部群同步：哪台机器/哪个服务已更新、验证方式（比如“调用
/api/v1/health返回 200”）
CI 和自动化标签决定你能不能坚持下去
再好的分支策略，没有自动化兜底就是纸面流程。关键不是配多复杂，而是守住两条线：main 分支每次 push 必须构建成功，每个 merge commit 必须自动生成语义化 tag。
- 用 GitHub Actions 或 GitLab CI，在
.github/workflows/ci.yml里定义：push 到main→ 安装依赖 → 运行测试 → 打包 → 推送镜像（如有） - 用
standard-version或semantic-release自动根据 commit message（如feat: add dark mode toggle）生成 tag 和 CHANGELOG，避免人工打错版本号 - 所有成员本地
git config --global pull.rebase true，防止 merge commit 污染历史，让git log --oneline看起来干净
最常被忽略的其实是权限和习惯：给所有人 main 的 push 权限，但靠 CI 卡住质量；鼓励每天至少一次 rebase 同步，而不是攒三天再 push 一堆冲突。分支越少，越得靠人盯紧那一条线。
