shop-platform/docs/GIT_REALEASE.md

适用于中大型团队的方案主要有两种：

---

✅ 推荐方案一：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

4. 禁止直接 push 到主干

   • 所有代码必须通过 PR/MR 合并

---

📌 总结：最优实践（推荐）

对于大多数现代企业后台服务，采用：
✅ Trunk-Based Development（主干开发） + 短生命周期 feature 分支 + 自动化 CI/CD
是最高效、可扩展、符合 DevOps 理念的方式。

只有在强版本管控、多客户定制、无法频繁上线等特殊场景下，才考虑 GitFlow。

---

如果你能提供更多信息（如团队规模、发布频率、是否微服务、CI/CD 成熟度），我可以给出更定制化的建议！