设计一个适合中型团队的Git分支策略

题目

设计一个适合中型团队的Git分支策略

信息

• 类型：问答
• 难度：⭐⭐

考点

Git工作流设计,分支管理策略,团队协作规范

快速回答

推荐使用改进的Git Flow工作流：

• 主分支：main（生产环境代码）和develop（集成测试分支）
• 辅助分支：feature/*（功能开发），release/*（预发布），hotfix/*（紧急修复）
• 关键规则：
  • 所有开发从develop切出feature分支
  • 功能完成后发起Pull Request合并到develop
  • 发布时从develop创建release分支测试
  • 通过测试后合并到main并打Tag

1. 核心分支结构

永久分支：

• main：始终反映生产环境状态，每次合并必须打Tag
• develop：最新开发成果的集成分支，用于每日构建

临时分支：

• feature/xxx：功能开发分支（例：feature/user-auth）
• release/v1.2：预发布分支，用于QA测试和bug修复
• hotfix/xxx：生产环境紧急修复分支

2. 工作流程示例

# 新功能开发
$ git checkout develop
$ git checkout -b feature/payment-gateway

# 开发完成后发起PR
$ git push origin feature/payment-gateway
# 在Git平台创建Pull Request到develop分支

# 发布流程
$ git checkout develop
$ git checkout -b release/v1.3
# 在release分支修复bug（不添加新功能）

# 发布生产
$ git checkout main
$ git merge --no-ff release/v1.3
$ git tag -a v1.3.0 -m "Production release"
$ git branch -d release/v1.3

# 紧急热修复
$ git checkout main
$ git checkout -b hotfix/login-issue
# 修复后同时合并到main和develop

3. 最佳实践

• 分支命名规范：使用type/description格式，如feat/search-optimization
• Pull Request要求：
  • 必须通过CI构建
  • 至少1人Code Review
  • 关联JIRA任务编号
• 提交规范：遵循Conventional Commits，例如：
  feat(payment): add Alipay integration [JIRA-123]

4. 常见错误

• 直接在main或develop分支提交代码
• feature分支生命周期过长（超过2周）导致合并冲突
• 忘记合并hotfix到develop造成代码丢失
• 未删除已合并的临时分支导致分支污染

5. 扩展知识

• 与CI/CD集成：
  • develop分支触发自动化测试
  • release/*分支触发预生产环境部署
  • Tag推送触发生产环境部署
• 环境对应：
  • main → 生产环境
  • release/* → 预发布环境
  • develop → 测试环境
• 替代方案：
  • 小型团队：GitHub Flow（更简单）
  • 超大型项目：Trunk-Based Development（需要更强CI）