19.7.2 版本管理策略与分支模型

在发布管理与变更控制中，版本管理策略与分支模型决定了交付质量与协作效率。本节以可落地为目标，给出版本号规范、分支模型、合并策略、标签基线与实操流程，并提供安装、排错与练习。

原理草图：版本与分支协作关系

1. 版本号规范与生命周期（含命令示例）
语义化版本（SemVer）：主版本.次版本.修订号
- 主版本：不兼容变更
- 次版本：兼容新增
- 修订号：缺陷修复

示例：生成版本号、写入制品清单

# 假设仓库目录为 /srv/git/app
cd /srv/git/app

# 以时间与提交生成构建号
BUILD_ID="$(date +%Y%m%d%H%M)-$(git rev-parse --short HEAD)"
VERSION="v1.4.2"
RC="v1.4.2-rc.1"

# 生成发布清单
cat > /srv/release/manifest.json <<'EOF'
{
  "version": "v1.4.2",
  "build_id": "202403121530-acde12",
  "git_commit": "acde12",
  "artifact": "app-1.4.2.tar.gz",
  "env": "prod"
}
EOF

# 打标签并推送
git tag -a "$VERSION" -m "release $VERSION"
git push origin "$VERSION"

2. 分支模型选择与适用场景（含流程示例）
- Git Flow：多版本并行，变更稳定
- Trunk-Based：高频发布，主干集成
- Release Branch：长期维护版本

Git Flow 实操（新功能发布）：

# 基于 develop 创建功能分支
git checkout develop
git pull origin develop
git checkout -b feature/login-rate-limit

# 开发提交
git add .
git commit -m "feat: add login rate limit"

# 合并到 develop（使用 PR，以下为本地示例）
git checkout develop
git merge --no-ff feature/login-rate-limit -m "merge feature/login-rate-limit"
git push origin develop

# 创建 release 分支
git checkout -b release/v1.4
git push origin release/v1.4

Trunk-Based 实操（短分支 + 特性开关）：

git checkout main
git pull origin main
git checkout -b feat/fast-export
# 代码中使用开关 FEATURE_FAST_EXPORT=true
git commit -am "feat: fast export behind flag"
git checkout main
git merge --squash feat/fast-export
git commit -m "merge feat/fast-export"
git push origin main

3. 合并与回溯策略（含配置与命令）
推荐：feature 使用 Squash，release 使用 Merge 保留上下文；Hotfix 双向回合并。
示例：Hotfix 流程

git checkout main
git pull origin main
git checkout -b hotfix/urgent-null-pointer

# 修复提交
git commit -am "fix: handle null pointer in auth"

# 合并到 main
git checkout main
git merge --no-ff hotfix/urgent-null-pointer -m "merge hotfix/urgent-null-pointer"
git tag -a v1.4.3 -m "hotfix v1.4.3"
git push origin main v1.4.3

# 回合并到 develop/release
git checkout develop
git merge --no-ff hotfix/urgent-null-pointer -m "back-merge hotfix"
git push origin develop

4. 标签与发布基线管理（含清单示例）
发布基线包含：构建号、提交哈希、制品版本、部署清单、环境信息。
示例：发布基线文件 /srv/release/baseline.yaml

release:
  version: v1.4.2
  build_id: "202403121530-acde12"
  git_commit: "acde12"
  artifact: "app-1.4.2.tar.gz"
  env: "prod"
  deploy:
    hosts:
      - 10.0.1.10
      - 10.0.1.11
    config_hash: "7f9a2c"

5. 多环境配置隔离（含示例）
建议环境通过配置层控制，避免 dev/test/prod 分支。
示例：Nacos/配置中心改为环境变量注入

# /etc/systemd/system/app.service
[Service]
Environment=APP_ENV=prod
Environment=CONFIG_SERVER=http://nacos.prod:8848
ExecStart=/opt/app/bin/app

6. 质量门禁与保护规则（示例配置）
示例：GitLab 保护分支策略建议
- main/release 禁止直推
- 合并需 2 人评审
- CI 必须通过

7. 安装与基础工具准备（Git）

# Debian/Ubuntu
apt-get update && apt-get install -y git

# RHEL/CentOS
yum install -y git

# 查看版本
git --version

8. 常见问题排错
- 问题1：标签推送失败
现象：rejected
处理：确认本地标签是否存在、权限是否允许

git tag -l | grep v1.4.2
git push origin v1.4.2

问题2：分支漂移导致冲突
处理：频繁合并，短生命周期分支

git checkout feature/xxx
git fetch origin
git rebase origin/develop

问题3：版本号与制品不一致
处理：流水线中统一生成版本号并注入清单

VERSION=$(cat VERSION)
echo "$VERSION" > /srv/release/VERSION

9. 练习与验收
1) 使用 Git Flow 创建 feature/api-timeout 并合并到 develop
2) 创建 release/v1.5 并打 v1.5.0-rc.1 标签
3) 模拟 hotfix 修复并回合并到 develop
4) 输出一份 /srv/release/baseline.yaml，包含版本与提交哈希
验收标准：主干提交线性、标签存在、基线文件完整、无环境分支

通过标准化版本命名、清晰分支职责、严格合并与可追溯基线，可显著降低发布风险并提升持续交付效率。