📚 课程目录第4章版本控制与分支策略

版本控制与分支策略：Git工作流与代码准入

版本控制这件事，说起来简单，做起来坑不少。我见过太多团队，Git用得很溜，但一到分支管理就乱成一锅粥。说白了，分支策略不是技术问题，是协作规范问题。

你想想看，如果没有统一的分支模型，每个人按自己习惯来，合并冲突只是小问题，真正要命的是：没人知道当前哪个分支是稳定的，哪个分支能上线，哪个分支还在开发中。

主流分支模型对比

我这些年带过的项目，主流分支模型就那么三种。每种都有适合的场景，没有银弹。

模型名称	核心分支	适用场景	我的建议
GitFlow	master, develop, feature, release, hotfix	有固定发版周期的产品	适合传统软件，但分支太多
GitHub Flow	main, feature	持续部署的Web应用	简洁，我一直在用
Trunk-based	main（或trunk），短期特性分支	高频率CI/CD团队	对自动化要求极高

关键点：不管选哪种模型，核心目的是让「代码从提交到上线」的路径清晰、可追溯、可回滚。

我推荐的部署分支模型

在部署流程持续验证的场景下，我个人习惯一种简化版模型，也是我们团队现在用的。它结合了GitHub Flow的简洁和Trunk-based的快速反馈。

# 分支命名规范
main        - 生产就绪分支，只接受PR合并
develop     - 集成分支，所有特性汇合点
feature/*   - 特性分支，从develop拉出
fix/*       - 修复分支，从develop拉出
release/*   - 预发布分支，从develop拉出，合并到main和develop
hotfix/*    - 紧急修复分支，从main拉出

嗯，这里要注意：main分支的每一次提交，都应该是经过验证、可以部署到生产环境的。develop分支则承担日常集成的角色。

小技巧：在develop上开启分支保护，强制要求PR通过CI检查和至少一名Reviewer。这能挡住大部分低级错误。

代码准入原则

代码准入不是玄学，是我踩过坑之后总结出来的硬规则。我在项目中遇到过好几次，开发人员直接推送代码到main，结果引发生产事故。从那以后，我定死了几条准入红线。

为什么会这样？因为人都会犯错，而流程是最后的防线。

准入检查清单

编译检查：代码必须无警告通过编译。我见过有人靠-Wno-error绕过，这种行为绝对不能容忍。
单元测试：测试覆盖率不低于80%，且新增代码必须有对应测试用例。
静态分析：使用工具扫描代码质量、安全漏洞。
集成测试：在分支合并前，跑完自动化集成测试套件。
代码审查：至少2名资深工程师批准PR。
无冲突：分支必须基于最新目标分支rebase或merge。

我曾经犯过的错：曾经为了赶上线，手动跳过了静态分析这一步。结果上线后才发现一个严重的SQL注入漏洞。从那以后，我把准入检查写成了CI脚本，任何跳过行为都会在日志里留下记录，并且触发告警。

Git Hooks与准入自动化

光靠自觉不行，得靠工具。我在团队里推广使用Git Hooks来落实本地准入检查。

# .git/hooks/pre-commit 示例
#!/bin/bash

echo "运行本地准入检查..."

# 编译检查
make build
if [ $? -ne 0 ]; then
    echo "编译失败，拒绝提交"
    exit 1
fi

# 运行单元测试
make test
if [ $? -ne 0 ]; then
    echo "单元测试失败，拒绝提交"
    exit 1
fi

echo "准入检查通过"

但这还不够。本地钩子可以被绕过。真正的防线在服务器端。

# CI配置示例（GitLab CI）
stages:
  - verify
  - test
  - deploy

variables:
  GIT_DEPTH: "0"  # 保证获取完整历史

verify:
  stage: verify
  script:
    - cmake -B build -DCMAKE_BUILD_TYPE=Release
    - cmake --build build
  only:
    - merge_requests
    - develop
    - main

test:
  stage: test
  script:
    - cd build && ctest --output-on-failure
  coverage: '/Coverage: \d+\.\d+%/'

deploy:
  stage: deploy
  script:
    - echo "部署到预发布环境"
  only:
    - main
  when: manual  # 人工确认后才能部署

一点经验：在develop和main分支上开启推送保护：只有项目维护者才能推送，其他成员必须通过合并请求（MR/PR）。同时开启合并前流水线检查，确保所有CI步骤通过才能合并。

分支策略与部署流程对应关系

你把分支策略和部署流程对应起来看，就清晰多了。我习惯用一张图来展现整个逻辑。

保护分支配置实战

我建议你在GitHub/GitLab上做的第一件事，就是配置分支保护规则。别等到出事了才想起这个。

# GitHub 分支保护配置示例（通过API）
# 注意：以下配置在仓库设置中手动操作也可

{
  "required_status_checks": {
    "strict": true,
    "contexts": ["continuous-integration/jenkins"]
  },
  "enforce_admins": true,
  "required_pull_request_reviews": {
    "required_approving_review_count": 2,
    "dismiss_stale_reviews": true
  },
  "restrictions": {
    "users": ["maintainer-team"],
    "teams": ["core-devs"]
  }
}

注意：分支保护规则不是摆设。一旦设置，所有人都必须遵守——包括项目经理和架构师。如果你发现有人能绕过规则直接推送，那保护就失效了。

合并策略的选择

合并到main或develop时，用什么策略？我做过对比，列出来你看看。

策略	历史记录	合并提交	适用场景
Merge Commit	保留完整分支历史	是	需要追溯分支来源
Squash Merge	压缩为单个提交	是	特性开发分支，保持主分支历史整洁
Rebase Merge	线性历史，无合并提交	否	追求干净线性历史

我个人习惯：特性分支用Squash Merge合并到develop，develop用Merge Commit合并到main。这样既保留了集成点的合并提交，又让特性历史看起来清爽。

诀窍：在PR描述中写清楚合入后需要执行的部署步骤。我要求团队在模板里包含「部署检查清单」字段，合并前必须逐项确认。

总结一下核心要点

分支策略选一个，坚持用下去。别今天GitFlow，明天Trunk-based。
代码准入不是选择题，是必答题。用CI脚本强制检查。
保护分支配置要到位，尤其是main和develop。
合并策略统一规范，避免历史混乱。
每一次合并到main，都对应一次经过验证的部署。