1. 问题背景：git push --force 引发的“血案”

2023年Q3，我们团队（后端6人、前端5人、测试4人）还在用“裸奔”式Git协作：所有人直接往master推代码，分支名随意（fix、test、final_v2）。结果：

  • 每周平均3次合并冲突，解决冲突耗时2小时+；
  • 2次误推master导致线上紧急回滚，其中一次是有人把本地没跑测试的代码直接push；
  • Code Review形同虚设：PR描述空白，reviewer只看diff大小，不看逻辑。

痛定思痛，我们决定引入一套可执行的Git工作流，而不是停留在PPT层面的“最佳实践”。

2. 环境与版本：我们用什么

  • Git：2.39.2（注意git switch和git restore是2.23+的特性）
  • GitHub：企业版（支持分支保护规则）
  • Jenkins：2.414.2，插件：Git Parameter、Multibranch Pipeline、Blue Ocean
  • 代码量：Java（Spring Boot）+ Vue，共约80万行，20个微服务仓库

3. 方案设计：三层分支策略 + 一条PR铁律

参考Vincent Driessen的Git Flow，但针对我们的发布节奏做了简化：

master（生产可部署）
  └── develop（集成测试分支）
        ├── feature/xxx（功能分支，从develop拉出）
        ├── release/1.2.0（发布分支，从develop拉出）
        └── hotfix/urgent-fix（热修，从master拉出，合并回master+develop）

核心铁律：
1. master和develop受保护，禁止直接push（GitHub分支规则强制）；
2. 所有feature/*必须发起PR到develop，PR描述必须填模板（包含测试步骤、影响范围）；
3. 至少1个reviewer批准 + CI通过（Jenkins阶段）才能合并；
4. 发布时从develop拉release/x.y.z，测试通过后合并到master并打tag。

这个设计解决了三个问题：冲突（因为分支生命周期短）、误推（保护规则兜底）、review流于形式（PR模板+必须批准）。

4. 核心实现：分支保护 + PR模板 + Jenkins多分支流水线

4.1 GitHub分支保护（在仓库Settings → Branches）

// 分支保护规则：master 和 develop
{
  "required_status_checks": {
    "strict": true,
    "contexts": ["continuous-integration/jenkins"]
  },
  "enforce_admins": true,
  "required_pull_request_reviews": {
    "required_approving_review_count": 1,
    "dismiss_stale_reviews": true
  },
  "restrictions": null
}

注意：strict: true表示要求分支是最新的（防止基于过期develop的PR合并），dismiss_stale_reviews表示代码变更后旧approve失效——这逼着大家重新review。

4.2 PR模板（.github/pull_request_template.md）

### 变更描述
- 为什么改：关联JIRA-123
- 改了什么：简述核心逻辑变化（不超过3句话）

### 测试步骤
- [ ] 本地跑通`mvn test`
- [ ] 启动后调`/health`接口验证
- [ ] 影响范围：/order/** 模块

### 截图/日志（如有）
- 贴关键日志或UI截图

### 自检清单
- [ ] 无`System.out.println`残留
- [ ] 无未使用的import
- [ ] 数据库变更已附迁移脚本

用这个模板，PR从“一句话”变成“结构化描述”，reviewer能快速定位风险点。实测PR平均review时间从15分钟降到8分钟。

4.3 Jenkins多分支流水线（Jenkinsfile核心片段）

pipeline {
    agent any
    triggers {
        // 每5分钟检查新分支，避免轮询过频
        pollSCM('H/5 * * * *')
    }
    stages {
        stage('检查') {
            when { branch 'feature/*' } // 只对feature分支跑轻量检查
            steps {
                sh 'git diff --check' // 检查空白错误
                sh 'echo "分支规范检查通过"'
            }
        }
        stage('编译') {
            steps {
                sh 'mvn clean compile -DskipTests -q' // 跳过测试，快速反馈
            }
        }
        stage('单元测试') {
            steps {
                sh 'mvn test -DfailIfNoTests=false --batch-mode' // 失败即中断
            }
            post {
                always {
                    junit '**/target/surefire-reports/*.xml' // 测试报告
                }
            }
        }
        stage('构建镜像') {
            when { branch 'release/*' } // 只有release分支构建Docker镜像
            steps {
                sh 'docker build -t registry.example.com/app:${GIT_COMMIT} .'
                sh 'docker push registry.example.com/app:${GIT_COMMIT}'
            }
        }
    }
    post {
        failure {
            // 推送到钉钉群，@负责人
            dingtalk(
                robot: 'your-robot-id',
                type: 'actionCard',
                text: "构建失败：${env.JOB_NAME} - ${env.BUILD_URL}"
            )
        }
    }
}

关键点：
- when { branch 'release/*' }避免feature分支也构建镜像（浪费资源）；
- 用git diff --check在编译前拦截空白错误——这个细节能减少reviewer的无效噪音；
- 测试报告用junit()收集，让Jenkins的测试趋势图可见。

5. 踩坑与优化：三个真实教训

5.1 教训一：develop分支的“长命”导致基因污染

现象：develop分支存在3周后，feature分支合并时总出现无关文件冲突（比如pom.xml版本号被反复改）。
原因：release分支合并回develop时用了git merge --no-ff，但没有同步master的tag版本。
解决：规定release合并到master后，必须立即将master合并回develop，并更新pom.xml版本号。

5.2 教训二：PR的strict: true导致“死循环”

现象：A的PR被B的合并导致“branch is out of date”，A需要不断git pull develop再push，一天重复5次。
优化：启用GitHub的“Update branch”按钮（需要GitHub Actions），或者在PR模板中约定“每天上班第一件事rebase develop”。

5.3 教训三：git bisect定位回归——不是所有回归都能靠代码review发现

场景：某次发版后订单接口P99延迟从200ms涨到800ms，没有报错。我们靠git bisect二分查找，在30次提交中定位到一次“日志级别由INFO改为DEBUG”的提交——因为日志量暴增拖垮了IO。
命令：

git bisect start
git bisect bad master
git bisect good v1.2.0
git bisect run grep -q "DEBUG" src/main/resources/logback.xml

这告诉我们：CI不仅要跑测试，还要跑性能基准。我们后来加了JMH微基准测试到release/*分支，超过阈值即失败。

6. 效果数据：对比前后

指标 实施前（Q3） 实施后（Q4） 变化
合并冲突数/周 3次 0.6次 -80%
误推master事故 2次/季度 0次 -100%
PR平均review时间 15分钟 8分钟 -47%
发布耗时 2天（手工+等待） 4小时（流水线） -75%
线上回归事件 每月1.5次 每季度0.5次 -67%

最大的收益不是速度，而是安全感：团队成员敢在周五下午提交代码，因为知道CI和分支保护会兜底。

7. 总结：这套工作流适合谁？

如果你的团队：
- 规模在10-50人；
- 使用GitHub/GitLab（支持分支保护）；
- 有Jenkins/GitLab CI基础；

那么这套“三层分支 + PR模板 + 多分支流水线”可以直接复制。但有几个前置条件要提前想清楚：
1. 测试速度：如果单测超过15分钟，开发者会绕过PR直接push——我们强制要求单测在5分钟内跑完；
2. review文化：工作流只是工具，真正的核心是“每个人都愿意花10分钟认真看别人的代码”；
3. 版本号管理：建议用maven-release-plugin或semantic-release自动化版本号，避免手动改pom.xml。

最后说一句有态度的话：Git工作流不是银弹，但它能把你从“救火”中解放出来，去做真正的代码设计。我们团队现在每周五下午做“代码走读+重构”，这在以前是不可想象的。