3、版本控制基础：Git工作流、分支策略（Git Flow、Trunk Based）、代码提交规范

版本控制是CI/CD流水线的基石。没有规范的分支管理与提交约定，自动化测试与部署将陷入混乱。本章聚焦于三种主流工作流、两种核心分支策略以及业界通用的提交规范，帮助你在Go Web服务项目中建立可追溯、可协作的版本控制体系。

3.1 Git工作流对比

不同的团队规模与发布节奏对应不同的Git工作流。下表从核心原则、适用场景与优缺点三个维度对比三种主流工作流：

3.2 分支策略：Git Flow vs. Trunk Based

分支策略决定了代码如何从开发走向生产。Git Flow与Trunk Based是两种最具代表性的策略，它们在发布节奏、分支寿命与团队协作方式上存在根本差异。

3.2.1 Git Flow

Git Flow定义了main、develop、feature、release、hotfix五类分支，形成一套严格的发布管理流程。

• main： 只存放已发布到生产环境的代码，每次合并都打Tag。
• develop： 日常开发集成分支，所有feature分支从此创建并合并回来。
• feature： 从develop创建，开发完成后合并回develop。
• release： 从develop创建，用于发布前的测试与Bug修复，完成后合并到main和develop。
• hotfix： 从main创建，用于紧急修复生产问题，修复后合并到main和develop。

3.2.2 Trunk Based Development（主干开发）

Trunk Based强调所有开发者直接向main（主干）提交小批量、高频次的代码，分支寿命通常不超过一天。

• 短分支： 分支只用于单个小功能或Bug修复，通常几小时内合并。
• 高频合并： 每天至少合并一次到主干，避免长期分支带来的合并地狱。
• 特性开关： 未完成的功能通过特性开关（Feature Toggle）隐藏，而非通过分支隔离。
• 持续集成： 每次提交都触发自动化构建与测试，确保主干始终可部署。

3.2.3 策略对比

3.3 分支策略流程图

下图展示了Git Flow与Trunk Based两种策略的核心流程差异：

3.4 代码提交规范

规范的提交信息（Commit Message）是版本控制可追溯性的关键。在CI/CD流水线中，提交信息甚至可以被解析用于自动生成变更日志（Changelog）或触发特定部署动作。

3.4.1 Conventional Commits 规范

业界最广泛采用的提交规范是 Conventional Commits，其格式如下：

<type>(<scope>): <description>

[optional body]

[optional footer(s)]

其中 <type> 是必填字段，表示提交的类型：

3.4.2 Go Web服务提交示例

feat(api): add user registration endpoint

- Implement POST /api/v1/users with email validation
- Add password hashing using bcrypt
- Return 201 with user ID on success

Closes #42

fix(db): resolve connection pool exhaustion under high load

- Increase MaxOpenConns from 10 to 50
- Add connection health check before query execution
- Log pool statistics for monitoring

Fixes #87

ci(docker): optimize multi-stage build for production image

- Use alpine-based Go image for final stage
- Remove build dependencies from runtime image
- Reduce image size from 800MB to 45MB

3.4.3 提交规范在CI/CD中的作用

规范的提交信息可以直接被CI/CD工具链解析，实现自动化流程：

• 自动生成Changelog： 工具如standard-version或semantic-release根据feat和fix类型自动计算版本号并生成变更日志。
• 触发特定流水线： 提交信息中包含ci:或docs:时，可以跳过部署流水线，只运行对应的检查任务。
• 关联Issue： 使用Closes #42或Fixes #87等footer，自动关闭关联的Issue或任务。
• 分支命名关联： 分支名如feat/user-registration与提交类型保持一致，便于自动化工具识别。

3.5 分支命名规范

分支命名与提交规范保持一致，可以提升仓库的可读性与自动化能力。推荐的分支命名格式如下：

3.6 版本控制与CI/CD的集成点

版本控制规范与CI/CD流水线的集成体现在以下几个关键环节：

1. 提交触发： 每次git push到特定分支（如main、develop、feature/*）触发对应的CI流水线。
2. 分支保护规则： 在Git仓库中设置分支保护，要求PR必须通过CI检查、代码审查且无冲突才能合并。
3. 语义版本自动计算： CI工具解析提交信息中的feat和fix类型，自动决定版本号的递增级别（MAJOR/MINOR/PATCH）。
4. 自动部署： 当main分支有新的feat或fix提交时，自动触发生产环境部署；docs或chore类型则跳过部署。
5. 变更日志生成： 在发布阶段，CI工具收集从上一个Tag到当前的所有提交信息，按类型分类生成结构化的Changelog。