Git工作流重构记：从混乱主干到分支策略与CI/CD落地

一、问题背景：我们是如何被“主干开发”拖垮的

去年下半年，团队扩张到12人，但Git使用方式还停留在“所有人往master推”。每天早上打开IDE，第一件事就是处理昨晚的冲突。更痛苦的是，每次发版都要“冻结代码”，大家停止一切提交，由一个人手动合并到release分支，再打tag。一次上线平均耗时2小时，而且经常出现“我明明改了这个文件，怎么上线后是旧的”这种诡异问题。

核心痛点总结：
- 无保护分支：任何人有写权限，误操作直接覆盖。
- 无Code Review：代码质量全凭自觉，线上Bug率一度冲到15%。
- 无自动化：测试、构建、部署全靠手动，发布窗口极长。

二、环境与版本：我们用的技术栈

• Git版本：2.39.2（macOS） / 2.40.1（Ubuntu 20.04 CI机器）
• 代码托管：GitLab CE 15.11（自建）
• CI/CD：Jenkins 2.414.2 + Docker 24.0.5
• 语言/框架：Java 11 + Spring Boot 2.7，前端Vue 3 + Vite

注意：以下配置均基于上述版本，Git 2.30以下的git switch命令可能不支持，请先升级。

三、方案设计：分层分支策略 + 强制PR流程

我们最终选择了Git Flow的简化变体（去掉了release分支的长期维护，改为短生命周期分支），结构如下：

main（生产环境，只接受merge request）
├── develop（开发主干，集成所有feature）
│   ├── feature/xxx（新功能，从develop切出）
│   ├── bugfix/xxx（修复，从develop切出）
└── hotfix/xxx（紧急线上修复，从main切出）

关键规则：
1. main和develop设为Protected Branch，仅Maintainer（2人）有合并权限。
2. 任何新功能必须从develop切出feature/分支，分支名必须包含需求单号（如feature/20240123-user-login）。
3. 禁止直接推送main和develop，所有变更必须通过Merge Request (MR) 进入。
4. MR必须关联至少1个Reviewer，并且通过CI流水线校验后，才允许合并。

四、核心实现：代码与配置细节

4.1 分支保护与MR模板（GitLab配置）

在GitLab项目设置中，我们通过.gitlab/merge_request_templates/default.md定义模板，强制填写变更描述：

## 变更内容
- 关联需求单号：[JIRA-1234]
- 变更类型：Feature/Bugfix/Hotfix
- 涉及模块：用户中心/订单服务

## 自测清单
- [ ] 本地通过`mvn test`
- [ ] 已运行`npm run lint`
- [ ] 无新增`System.out.println`

## 测试说明
- 测试环境是否验证通过？(是/否)
- 是否涉及数据库变更？(是/否，需附迁移脚本)

4.2 CI/CD集成：Jenkinsfile核心片段

我们在Jenkins中创建了流水线任务，监听develop和main分支的变动。以下是一段简化版的Jenkinsfile，重点展示多阶段校验：

pipeline {
    agent { docker { image 'maven:3.8.8-eclipse-temurin-11' } }
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Unit Test') {
            steps {
                sh 'mvn test -DskipTests=false -DfailIfNoTests=false'
            }
            post {
                success { junit '**/target/surefire-reports/*.xml' }
            }
        }
        stage('SonarQube Analysis') {
            steps {
                // 假设SonarQube已通过插件配置
                withSonarQubeEnv('SonarQube') {
                    sh 'mvn sonar:sonar -Dsonar.projectKey=my-project'
                }
            }
        }
        stage('Build Docker Image') {
            when { branch 'main' }
            steps {
                sh 'docker build -t myregistry.com/myapp:${GIT_COMMIT} .'
                sh 'docker push myregistry.com/myapp:${GIT_COMMIT}'
            }
        }
    }
    post {
        failure { 
            // 微信通知
            notifyWechat('构建失败，请查看日志') 
        }
    }
}

关键点：
- 在Unit Test阶段，我们增加了-DfailIfNoTests=false，避免因某个模块没有测试文件而中断流水线。
- 只有当分支为main时，才构建Docker镜像并推送，develop分支只跑测试和SonarQube。

4.3 本地钩子：强制Commit规范

为了减少无意义的提交信息，我们写了一个commit-msg钩子（存放在hooks/目录），用正则校验：

#!/bin/sh
# 文件名: .git/hooks/commit-msg
commit_msg=$(cat "$1")
# 匹配格式: [JIRA-1234] feat: 描述
if ! echo "$commit_msg" | grep -qE '^(\[JIRA-[0-9]+\] )?(feat|fix|docs|style|refactor|test|chore)(\(.+\))?:' ; then
    echo "ERROR: Commit message must match format: [JIRA-1234] feat(module): description" >&2
    exit 1
fi

五、踩坑与优化：我们掉过的坑

坑1：develop分支的“脏”提交
刚开始时，有人图省事，直接在develop上修了一个小Bug，导致develop与main的差异越来越难追踪。后来我们严格执行“任何变更必须走MR”，并在MR描述中要求勾选“自测清单”，否则自动关闭。

坑2：CI流水线误报
第一次接入SonarQube时，因为新代码没有覆盖率阈值，导致流水线一直红色。解决方案：在pom.xml中设置jacoco插件的haltOnFailure为false，先让流水线跑通，再逐步收紧阈值：

    org.jacoco
    jacoco-maven-plugin
    0.8.11

        false

坑3：git rebase与git merge之争
我们一开始规定feature分支必须用rebase变基到最新develop，但发现很多人rebase后冲突解决得一塌糊涂。后来改为仅允许merge（用--no-ff保留合并记录），虽然历史会有“泡菜串”，但冲突解决更直观。现在我们在MR页面强制勾选“Squash commits”选项，历史干净很多。

六、效果数据：重构前后的对比

经过一个月的调整和执行，我们统计了以下数据（对比重构前3个月和重构后3个月）：

最有价值的改进：不是某个工具，而是“任何变更可追踪”。现在回滚一个功能，只需要git revert，并且能通过git log --oneline --graph清晰看到所有分支的脉络。

七、总结：这套工作流适合你吗？

这套方案在12人的Java后端团队中验证有效，但并非银弹。如果你满足以下条件，建议参考：
- 团队规模在5-20人之间
- 需要每周至少一次发版
- 有专人维护CI（Jenkins/GitLab CI均可）

如果你是一个人开发，或者3人以下小团队，建议直接使用GitHub Flow（单一main分支 + 短分支），性价比更高，别折腾Git Flow。

最后，分享一个排查回归的小技巧：如果上线后发现问题，用git bisect自动定位是哪个提交引入的。三步搞定：

git bisect start
git bisect bad main  # 当前版本是坏的
git bisect good v1.0.0  # 上一个正常版本
# 随后Git会切换中间提交，你只需执行测试命令，然后git bisect good/bad

希望这篇笔记能帮你少踩几个坑。如果有疑问，欢迎在评论区交流，我看到了会回复。