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 类垃圾分支堆积

容易踩的坑：

Workspace Git Setup

一键在任意工作目录中设置 Git 跟踪，并附带安全为重点的 .gitignore（包括凭证、TLS/SSH 私钥、令牌、运行时缓存和 PID 等）

下载

• 用中文或空格命名分支（如 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 才是完整语义单元。