3.7 KiB
3.7 KiB
1. 主流分支策略（最核心的部分）
大型公司很少用最简单的“所有人直接推 main”，而是根据团队规模、发布频率和合规要求选择以下策略：
| 策略 | 适用场景 | 核心分支 | 特点 | 代表公司/团队 |
|---|---|---|---|---|
| GitFlow（经典） | 大型团队、计划发布周期（如月度/季度）、需要维护多个版本 | main（生产）、develop（开发主线）、feature/*、release/*、hotfix/* |
结构清晰、适合复杂项目，但分支生命周期长，合并冲突较多 | 传统企业、金融、需要 LTS 版本的产品 |
| GitHub Flow（简化） | Web/云服务、中大型团队、频繁部署 | main + 短生命周期 feature/* 或 issue-xxx |
一切通过 PR，所有变更必须 Review | 很多互联网公司、开源项目 |
| Trunk-Based Development (TBD，主干开发) | 极大规模团队、高频 CI/CD、微服务 | 主要一个 main/trunk，极短分支（几小时~几天） |
最现代，强调 Feature Flag + 小步快跑，合并冲突最少 | Google、Meta、字节跳动（部分）、Netflix 等 |
当前趋势（2025-2026）：越来越多大型公司向 Trunk-Based 或其变体迁移，尤其是采用微服务 + 完善的 CI/CD + Feature Toggle 的团队。因为 GitFlow 的长期分支在百人以上团队中容易导致“分支地狱”。
2. 仓库形态
- Monorepo（单仓）：一个巨大仓库放多个服务/模块（如 Google、字节、Meta）。好处是原子提交、统一依赖管理；坏处是仓库巨大，需要特殊工具（Bazel、Nx 等）。
- Multi-repo（多仓）：每个服务/业务域一个仓库。更常见于传统大型企业和微服务初期。
- 混合模式：核心业务 Monorepo + 外围服务 Multi-repo。
3. 权限分配（企业级重点）
正规大公司不会给所有人 push 到 main 的权限，通常分层管理：
- Owner / Admin：项目负责人、架构师、Tech Lead（极少数人）
- Maintainer：可合并 PR、管理分支、设置保护规则
- Developer / Member：可创建分支、提 PR、Review 代码（主流权限）
- Read-only / Guest：测试、PM、外部合作方 常见保护规则（Protected Branch）：
main/master：必须 PR + 至少 2 人 Review + CI 通过 + 特定角色才能合并develop（如果有）：可放宽但仍需 Reviewrelease/*：严格控制- 强制线性历史（Require linear history）、禁止 force push 平台层面：
- GitHub Enterprise / GitLab / Gitee 企业版 / Azure DevOps / Bitbucket 最常用。
- 通过 Teams / Group 批量分配权限（推荐）。
- Code Owner 机制：特定目录必须特定团队 Review。
4. 典型开发流程（大型公司标准）
- 领任务 → 从
main或develop拉 短分支（feature/xxx或user/你的名字/功能） - 本地开发 + 自测 → 频繁 commit（小步提交）
- 提 PR/MR → 必须关联 Issue/Task，写好描述 + 测试用例
- 自动化检查：CI（单元测试、代码扫描、构建）必须通过
- Code Review（至少 1-2 人）
- 合并 → 自动或手动部署到测试/预发/生产
- Hotfix：直接从
main拉 hotfix 分支，紧急修复后双合并（main + develop）
额外最佳实践（大公司都在做）
- Commit Message 规范：Conventional Commits（
feat:、fix:、chore:等） - 分支命名规范：
feature/模块-功能、bugfix/xxx、hotfix/xxx - Feature Flag：大型团队必备，避免长分支
- 代码所有者（CODEOWNERS） 文件
- 定期 Rebase / Squash Merge 保持历史干净