GitHub Flow更适配敏捷开发，因其仅需main和feature/*分支，PR合并即部署，支持高频迭代；而GitFlow含5类分支、路径复杂，易在短周期迭代中积压，违背“小步快跑”原则。
敏捷开发中，Git分支策略必须轻量、高频、可预测——GitHub Flow 是当前最匹配的选择，而不是 GitFlow。
为什么 GitHub Flow 比 GitFlow 更适合敏捷团队
GitFlow 要求维护 main、develop、feature/*、release/*、hotfix/* 五类分支，合并路径复杂，PR 审查链路长，在两周一个迭代的节奏下极易积压。GitHub Flow 只保留 main 和 feature/*（或 bugfix/*），所有变更都通过 Pull Request 合并到 main，CI 通过即部署，符合“小步快跑、快速验证”的敏捷内核。
常见错误现象：
- 团队用 GitFlow 却跳过
develop直接往main提 PR，导致分支语义混乱 - 为赶迭代在
feature分支里塞进多个需求，PR 体积过大，Review 效率骤降 - 误将
hotfix合入develop而非main，线上问题修复延迟上线
关键判断依据：
- 如果团队每天有 ≥2 次生产部署，选 GitHub Flow
- 如果发布周期固定为 6 周且需灰度验证，才考虑 GitFlow 改良版
- 微服务架构下，每个服务应独立采用 GitHub Flow，不强求全栈统一分支模型
feature 分支命名与生命周期管理
分支不是越长越好，而是要能被自动解析、关联需求、触发对应 CI 流水线。Lobster AI 实践中强制要求：feature/模块名-需求单号，例如 feature/user-login-JIRA-456。
这样做不只是为了好看：
- CI 系统可基于前缀
feature/自动启用单元测试 + 接口冒烟，跳过耗时的端到端测试 - 代码扫描工具能将该分支的漏洞报告绑定到 JIRA-456 下，避免问题漂移
- 分支删除策略明确：PR 合并后 24 小时自动清理，防止
feature/xxx-old类垃圾分支堆积
容易踩的坑：
- 用中文或空格命名分支（如
feature/用户登录），某些 CI 工具无法识别，触发失败 - 分支长期不合并（>7 天），与
main的 diff 超过 300 行，冲突概率陡增，建议每日git rebase main同步基线 - 把个人实验性分支推到远程（如
feature/tom-test），污染团队分支列表
main 分支保护规则怎么设才真正起作用
光是点开 GitHub/GitLab 的 “Require pull request reviews before merging” 不够。真正起效的保护项必须组合使用：
- ✅ 必须开启：
Require status checks to pass before merging（绑定 CI job 名，如ci/unit-test、ci/security-scan） - ✅ 必须开启：
Include administrators（否则管理员可绕过所有检查直接 push） - ✅ 必须开启：
Require linear history（禁用 fast-forward，确保每次合并生成 merge commit，历史可追溯） - ❌ 不推荐：
Require signed commits（增加新人上手成本，且对敏捷高频提交无实质安全增益）
性能影响注意点：
- 如果
main上启用了 5 个以上 status check，平均 PR 合并等待时间会从 2 分钟拉长到 8 分钟以上，建议将非核心检查（如文档生成）设为 non-blocking - GitLab 用户注意：
protected branches的权限粒度比 GitHub 细，但Allowed to merge若只设Maintainers，会导致Developers组无法发起合并，需额外配置Allowed to push权限
如何让每次 git log 都能还原出上下文
Conventional Commits 不是仪式感，而是给自动化工具喂数据。Java/Python 项目中，feat(user): add OAuth2 login 这样的提交，能让 changelog 工具自动生成版本说明，也能让 Sentry 报错自动关联到引入该功能的 commit。
实操建议：
- 用
husky+commitlint在本地校验，不满足格式的git commit直接失败，不依赖人工记忆 - 作用域（括号内）必须真实存在，比如写
feat(api)就要有api/目录，否则后续做模块级统计会失真 - 禁止出现
update、fix bug、adjust这类无信息量的描述，CI 流水线可配置正则拦截
最容易被忽略的一点：当多人协作修改同一功能时，不同人的 feat(user) 提交可能分散在 3 天内，但 PR 标题必须统一为 feat(user): add OAuth2 login (JIRA-456)——提交历史是碎片，PR 才是完整语义单元。
