128 lines
4.8 KiB
Markdown
128 lines
4.8 KiB
Markdown
适用于中大型团队的方案主要有两种：
|
||
|
||
---
|
||
|
||
## ✅ 推荐方案一：**GitFlow（适合版本发布节奏明确的项目）**
|
||
|
||
### 📌 核心分支说明
|
||
|
||
| 分支 | 作用 | 生命周期 | 是否长期存在 |
|
||
|------|------|--------|------------|
|
||
| `main`（或 `master`） | **生产环境代码**，每个 commit 对应一个可发布版本 | 永久 | ✅ |
|
||
| `develop` | **集成开发分支**，最新开发成果，用于测试环境部署 | 永久 | ✅ |
|
||
| `feature/*` | 功能开发分支（如 `feature/user-auth`） | 临时 | ❌ |
|
||
| `release/*` | 发布准备分支（如 `release/v1.2.0`） | 临时 | ❌ |
|
||
| `hotfix/*` | 紧急线上修复分支（如 `hotfix/login-bug`） | 临时 | ❌ |
|
||
|
||
### 🔁 典型流程
|
||
|
||
1. **日常开发**
|
||
- 从 `develop` 拉出 `feature/xxx`
|
||
- 开发完成后，**PR/MR 合并回 `develop`**
|
||
|
||
2. **准备发布**
|
||
- 从 `develop` 拉出 `release/vX.Y.Z`
|
||
- 在此分支修复 bug、更新版本号、生成 changelog
|
||
- 测试通过后：
|
||
- 合并到 `main`（打 tag，如 `v1.2.0`）
|
||
- 合并回 `develop`（同步修复）
|
||
|
||
3. **紧急修复**
|
||
- 从 `main`（或对应 tag）拉出 `hotfix/xxx`
|
||
- 修复后：
|
||
- 合并到 `main`（打新 patch tag，如 `v1.2.1`）
|
||
- 合并到 `develop`
|
||
|
||
### ✅ 优点
|
||
- 版本清晰，适合有明确发布周期的系统（如每月发版）
|
||
- 支持并行开发与紧急修复
|
||
- `main` 始终代表线上状态
|
||
|
||
### ⚠️ 缺点
|
||
- 分支较多，对小型团队略显复杂
|
||
- 不适合持续部署（CI/CD 频繁上线）场景
|
||
|
||
---
|
||
|
||
## ✅ 推荐方案二：**Trunk-Based Development + Release Branches（适合 DevOps / 持续交付）**
|
||
|
||
> 越来越多互联网公司（如 Google、Facebook、Netflix）采用此模式，尤其适合**高频发布、自动化 CI/CD** 的后台服务。
|
||
|
||
### 📌 核心分支说明
|
||
|
||
| 分支 | 作用 |
|
||
|------|------|
|
||
| `main`（或 `trunk`） | **唯一主干分支**，所有开发直接或间接流向这里，保持可随时发布状态 |
|
||
| `release/*`（可选） | 仅在需要维护多个线上版本时使用（如 `release/v1.3`） |
|
||
| `feature/*`（短生命周期） | 功能分支，**必须短（<1天~2天）**，通过 PR 快速合并到 `main` |
|
||
|
||
> 💡 实践中常配合 **Feature Toggle（功能开关）**，即使未完成的功能也可合入 `main`，但默认关闭。
|
||
|
||
### 🔁 典型流程
|
||
|
||
1. 开发者从 `main` 拉出短命 `feature/xxx`
|
||
2. 提交 PR → 自动化测试（单元、集成、安全扫描）→ Code Review
|
||
3. 合并到 `main`
|
||
4. **CI/CD 自动部署到测试/预发环境**
|
||
5. 人工验证后，**一键发布到生产**（或自动金丝雀发布）
|
||
6. 若需回滚，直接回退 `main` 的 commit 或触发回滚流程
|
||
|
||
### ✅ 优点
|
||
- 极简分支模型，减少合并冲突
|
||
- 支持每天多次发布
|
||
- 与现代 CI/CD 工具链（Jenkins, GitLab CI, ArgoCD 等）天然契合
|
||
|
||
### ⚠️ 要求
|
||
- 强大的自动化测试覆盖（>80%）
|
||
- 快速 Code Review 文化
|
||
- 监控与快速回滚能力
|
||
|
||
---
|
||
|
||
## 🏆 企业后台服务推荐选择
|
||
|
||
| 场景 | 推荐策略 |
|
||
|------|--------|
|
||
| **传统企业、月度/季度发版、强合规要求** | ✅ **GitFlow** |
|
||
| **互联网公司、SaaS 服务、每日/每小时发布** | ✅ **Trunk-Based + Short-lived Feature Branches** |
|
||
| **混合模式（主干开发 + 定期大版本）** | 主干开发为主，大版本前切 `release` 分支 |
|
||
|
||
> 🔔 **当前趋势**：越来越多企业后台服务（尤其是微服务架构）倾向于 **Trunk-Based**，因为：
|
||
> - 后台服务通常无“客户端版本”约束
|
||
> - 可独立部署、灰度发布
|
||
> - 自动化程度高
|
||
|
||
---
|
||
|
||
## 🔐 补充建议（无论哪种策略）
|
||
|
||
1. **保护关键分支**
|
||
- 在 GitHub/GitLab 中设置：
|
||
- `main` / `develop` 为 **protected branch**
|
||
- 要求 **PR/MR + 至少1人审批 + CI 通过**
|
||
- （可选）要求 **GPG 签名提交**
|
||
|
||
2. **标准化 Commit & PR 模板**
|
||
- 使用 Conventional Commits（如 `feat:`, `fix:`, `chore:`）
|
||
- 自动生成 changelog 和版本号（配合 semantic-release）
|
||
|
||
3. **Tag 语义化版本**
|
||
- 所有生产发布必须打 tag：`v1.2.3`
|
||
- 格式遵循 [SemVer](https://semver.org/)
|
||
|
||
4. **禁止直接 push 到主干**
|
||
- 所有代码必须通过 PR/MR 合并
|
||
|
||
---
|
||
|
||
## 📌 总结：最优实践（推荐）
|
||
|
||
> **对于大多数现代企业后台服务，采用：**
|
||
> **✅ Trunk-Based Development（主干开发） + 短生命周期 feature 分支 + 自动化 CI/CD**
|
||
> 是最高效、可扩展、符合 DevOps 理念的方式。
|
||
|
||
只有在**强版本管控、多客户定制、无法频繁上线**等特殊场景下，才考虑 GitFlow。
|
||
|
||
---
|
||
|
||
如果你能提供更多信息（如团队规模、发布频率、是否微服务、CI/CD 成熟度），我可以给出更定制化的建议！ |