Git 中的 Release Branch — 什么是发布分支、用途和工作流程

Git 中的 Release Branch 是什么

Release Branch（发布分支）——是 Git Flow 中的一个临时分支，从 develop 创建，当团队决定当前功能集准备好发布时。这个分支存在的时间正好是最终准备发布所需要的时间——从几小时到几天不等。

发布分支的主要目的——冻结特定功能集用于发布，而不停止后续版本的开发。当发布分支正在准备发布时，其他开发人员可以继续将功能分支合并到 develop 中以备下一次发布。

在发布分支中不创建新功能——只进行问题修复、应用程序版本更新、本地化和文档。所有工作完成后，发布分支合并到 main（标记为发布）并合并回 develop（以便问题修复进入未来版本）。

根据 Atlassian, 2024 的说法，发布分支对于具有定期发布周期的项目至关重要——它们确保发布过程的可预测性和稳定性。

发布分支的生命周期

生命周期——发布分支从创建到删除包括几个阶段。理解每个阶段有助于团队同步行动并避免错误。

1. 创建——从 develop 的最新提交创建名为 release/2.5.0 的分支。develop 继续接受下一个版本的功能分支。
2. 准备——在发布分支中，更新 build.gradle、Info.plist 和其他配置文件中的应用程序版本。
3. 修复问题——修复最终测试过程中发现的关键问题。只修复问题——不添加新功能。
4. 最终测试——QA 团队在发布分支上进行回归测试。新问题被发送到同一分支进行修复。
5. 合并到 main——发布分支使用 --no-ff 标志合并到 main。创建发布标签：v2.5.0。
6. 合并到 develop——发布分支合并回 develop，以便发布中的问题修复进入当前开发。
7. 删除——发布分支在本地和远程被删除，因为它的任务已完成。

第 6 点——合并回 develop——经常被遗忘，但这至关重要。没有这一步，在发布中进行的问题修复将不会进入 develop，在下一次发布中同样的问题可能会再次出现。

发布分支各阶段的典型持续时间

发布分支的生命周期取决于发布的复杂性和 develop 中代码的质量。对于中等规模的移动应用程序，平均准备时间为 2 到 5 个工作日。

发布分支中做什么

在发布分支中执行严格受限的任务集。任何偏离此列表的行为都会违反 Git Flow 模型并对发布的稳定性造成风险。

禁止新功能规则——发布分支中最重要的一条。如果功能未能赶上发布，就等待下一个周期。试图将未完成的功能推入发布分支——是截止日期延误和生产中问题的首要原因。

在移动项目中更新版本

在发布分支中必须更新应用程序的版本号。对于 Android，这是 build.gradle 中的 versionCode 和 versionName 字段，对于 iOS——Info.plist 中的 CFBundleShortVersionString。

// build.gradle（应用级）——在发布分支中更新版本
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// 对于 iOS——更新 Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Release 和 Hotfix 的区别

初学开发人员经常混淆 release 和 hotfix 分支，尽管它们的用途根本不同。选择分支类型的错误可能导致关键修复延迟或发布过程中断。

• 来源——release 从 develop 创建，hotfix 从 main 创建。这是决定其他一切的主要区别。
• 紧急性——release 是计划性的：团队自己决定何时开始准备。Hotfix 是紧急的：生产中的问题需要立即修复。
• 内容——release 可以包含多个修复和版本更新。Hotfix 只包含一个关键修复。
• 合并——release 合并到 main 和 develop。Hotfix 也合并到 main 和 develop，但按优先级处理。
• 生命周期——release 持续 1 到 7 天。Hotfix 持续 30 分钟到 1 天。

如果在发布准备过程中（在 release 分支中）发现问题——这是普通的问题修复。如果在生产中（在 main 上）发现问题——这是 hotfix，它从 main 创建，即使发布分支已经存在。

发布分支的命名规则

统一的发布分支命名标准简化了仓库中的导航，并允许 CI/CD 系统自动确定该分支与发布过程相关。

• release/X.Y.Z——Git Flow 的标准格式，其中 X.Y.Z 是发布版本。示例：release/2.5.0。
• release/名称——带有发布代码名称的替代格式。示例：release/merlin。
• release/日期——带有发布日期的格式。很少使用，因为版本比日期更重要。示例：release/2024-12-01。

release/X.Y.Z 格式——更可取，因为它将分支与将要分配给发布的版本号明确关联。这简化了搜索和 CI/CD 脚本的自动处理。

合并回 develop 的策略

合并回（merge back）发布分支到 develop——是最重要但也经常被忽略的操作之一。没有这一步，发布中做的所有问题修复将只保留在发布版本中，不会进入下一个发布周期。

合并回过程在发布分支已合并到 main 之后执行。首先 release 合并到 develop，然后——删除。这保证 develop 包含发布准备过程中进行的所有修复。

合并回后可能出现冲突——特别是如果在 develop 中已经出现了修改相同文件的新功能分支。负责发布的开发人员解决这些冲突并将 develop 推送到服务器。

一些团队使用 rebase 而不是 merge 进行合并回，以保持历史线性。然而，merge 对 develop 更安全，因为它不会重写可能已被其他开发人员使用的提交历史。

处理发布的命令示例

让我们看看发布分支的完整工作周期：从创建到成功发布 2.5.0 版本移动应用程序后删除。

# 1. 从 develop 创建发布分支
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. 更新版本和问题修复
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. 修复问题（仅限 bugfixes）
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. 将发布分支推送到服务器
git push origin release/2.5.0

# 5. 将 release 合并到 main
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. 合并回 develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. 删除发布分支
git branch -d release/2.5.0
git push origin --delete release/2.5.0

命令 5 和 6——双重合并——至关重要。首先 main 接收发布代码和标签，然后 develop 与 release 的问题修复同步。如果跳过步骤 6，发布中的修复将不会进入下一个开发周期。

发布过程的自动化

对于有定期发布的移动项目，通过 CI/CD 脚本可以自动化创建发布分支和更新版本的过程。GitHub Actions 允许创建一个工作流，点击按钮即可创建带有自动版本更新的发布分支。

对于有定期发布的移动项目，通过 CI/CD 脚本可以自动化创建发布分支和更新版本的过程。GitHub Actions 允许创建一个工作流，点击按钮即可创建带有自动版本更新的发布分支。

# GitHub Actions——创建发布分支的自动化
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}