设计一个支持CI/CD的Git分支策略

题目

设计一个支持CI/CD的Git分支策略

信息

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

考点

分支管理策略,持续集成/持续交付（CI/CD）,Git工作流

快速回答

推荐使用Gitflow或Trunk-Based开发分支策略：

• 主分支：main分支存放生产环境代码，通过标签管理版本
• 开发分支：develop分支作为集成测试环境基准（Gitflow）
• 特性分支：从develop拉取，命名规范如feature/xxx
• 发布分支：release/v1.0用于预发布环境测试
• CI/CD集成：特性分支提交触发自动化测试，合并到develop触发集成测试

一、核心分支策略设计

推荐方案（Gitflow变体）：

main         - 生产环境代码（仅允许合并发布分支）
│
└── release/v1.0 - 预发布分支（UAT测试）
    │
    └── develop   - 集成测试环境基准
        │
        ├── feature/login   - 特性分支
        └── hotfix/payment-error - 热修复分支

二、CI/CD集成原理

• 特性分支：每次push触发单元测试和代码扫描

  # .gitlab-ci.yml 示例
  feature-test:
    only:
      - /^feature\/.*$/
    script:
      - npm run test
      - sonar-scanner

• develop分支：合并时触发集成测试和构建Docker镜像
• release分支：创建时触发UAT环境部署和压力测试
• main分支：合并后自动部署到生产环境（需审批）

三、最佳实践

1. 分支生命周期：
   • 特性分支存活时间 ≤ 2天（通过小批量提交避免冲突）
   • 发布分支在版本上线后立即删除
2. 代码合并：
   • 使用Rebase代替Merge保持提交历史线性
   • 强制Code Review（Pull Request机制）
3. 自动化门禁：
   • 合并前要求：单元测试覆盖率 ≥ 80%
   • 构建失败自动阻止合并

四、常见错误

五、扩展知识

• Trunk-Based开发：适用于高频发布场景（每日多次），所有开发者直接向main分支提交
• 环境对应策略：
  • feature分支 → 开发环境
  • develop分支 → 测试环境
  • release分支 → 预发布环境
  • main分支 → 生产环境
• Git钩子应用：通过pre-commit钩子强制代码规范

  #!/bin/sh
  # 示例pre-commit钩子
  if ! npm run lint; then
    echo "Lint检查失败！"
    exit 1
  fi