Hotfix Branch：什么是热修复分支，如何在移动开发中创建和应用

什么是Hotfix Branch？

Hotfix Branch（热修复分支）— 是Git中的一个临时分支，用于快速修复运行中生产环境的关键缺陷。与feature分支不同（feature分支从develop分支创建，存在数天或数周），热修复分支从main/master创建，其存在时间恰好等于修复错误所需的时间。

热修复分支的主要任务 — 最小化从发现关键错误到在生产环境中修复它的时间。团队无需等待当前冲刺或发布周期结束，而是立即发布补丁。这对于移动应用尤其重要，因为关键错误可能阻止用户操作并导致用户流失。

根据Google Play Console的数据，Google Play中更新的平均审核时间为2到24小时。App Store的快速审核可能需要1到4小时。热修复分支允许在审核完成前就准备好修复，并在批准后立即发布。

Hotfix的工作原理

热修复过程包括三个步骤：从main创建分支、进行修复、合并回main和develop。与普通修复的关键区别在于 — 热修复分支始终合并到两个分支中，以确保修复不会在下次发布时丢失。

团队不应向热修复分支添加新功能或重构代码。仅需进行消除关键问题所需的最小修复。任何偏离此规则的行为都会增加回归风险并延长补丁发布的时间。

何时需要Hotfix

在三种情况下需要热修复分支：关键错误阻止用户（崩溃、数据丢失）、安全漏洞需要立即修复、或关键业务逻辑被破坏（支付、认证）。如果错误不关键 — 可以通过develop在常规发布周期内修复。

对于移动应用，如果架构允许远程切换功能（功能开关），热修复分支也可以包含服务器端更改。在这种情况下，热修复分支可以是最小的，或者如果修复在服务器端进行，则根本不需要。

分支模型与Hotfix的位置

并非所有分支模型都支持热修复分支。传统的Git Flow将热修复分支作为完整的分支类型，而更现代的方法（GitHub Flow、Trunk-based）则以不同方式解决紧急修复问题。

Git Flow与Hotfix

Git Flow — 是唯一将热修复分支作为与feature和release并列的内置分支类型的模型。在Git Flow中，热修复分支从main创建，完成后合并到main（带版本标签）和develop。这保证了修复不会在下次发布中丢失。

GitHub Flow和Trunk-based

GitHub Flow不使用单独的分支类型进行热修复。相反，开发人员从main创建常规feature分支，进行修复并打开Pull Request。经过审核和CI检查后，分支合并到main并立即部署。优点 — 简单，缺点 — 缺乏紧急修复的单独通道。

Trunk-based开发通过直接提交到main（针对关键情况）并强制事后审核来解决热修复问题。这种方法需要高度的团队纪律和可靠的自动化测试，因为更改会立即进入生产环境。

如何创建Hotfix Branch

创建热修复分支从切换到主分支并以hotfix/前缀创建新分支开始。让我们以修复移动应用中的关键错误为例，逐步查看这个过程。

从main创建分支

第一步 — 切换到main并确保分支是最新的。然后创建一个名称清晰反映修复本质的热修复分支。

# 切换到main并获取最新更改
git checkout main
git pull origin main

# 创建热修复分支
git checkout -b hotfix/crash-on-login

创建分支后可以进行修复。重要提示：热修复分支应包含最少的更改。不要重构代码或添加新功能 — 只进行消除问题的针对性修复。

记录修复

提交在热修复分支中应有包含信息量的消息，清楚描述问题和解决方案。格式：类型(领域)：简短描述 + 跟踪器中的任务链接。

# 添加修改后的文件
git add src/ui/login/LoginActivity.kt

# 创建带描述的提交
git commit -m "fix(login): handle null intent on activity resume

Fixes CRASH-142: NullPointerException when LoginActivity
receives onNewIntent after being destroyed by system"

提交消息应包含问题描述和任务链接。这简化了历史搜索，并帮助同事了解修复了什么以及为什么修复。对于移动项目，通常还会注明发现错误的应用程序版本。

合并到main和develop

最后一步 — 将热修复分支合并回main（带新补丁版本标签）和develop（以便修复在下次发布中保留）。首先创建带标签到main的合并，然后创建到develop的合并。

# 合并到main并创建标签
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# 合并到develop
git checkout develop
git merge --no-ff hotfix/crash-on-login

# 将更改推送到服务器
git push origin main --tags
git push origin develop

--no-ff标志确保创建合并提交，即使热修复分支可以通过快进合并应用。这保留了进行紧急修复的信息，并简化了未来的历史分析。

Hotfix与Feature和Release分支的区别

Hotfix在目的、生命周期和合并规则上与feature和release分支有本质区别。理解这些区别对于在团队中正确组织Git流程至关重要。

Feature分支用于新功能。它存在几天到几周，从develop创建并合并回develop。Feature分支可以包含许多提交，包括实验性提交，之后通过squash或rebase压缩。

Release分支准备发布。它从develop创建，修复在稳定化过程中发现的错误，不接受新功能。完成后，release合并到main（带标签）和develop。

Hotfix直接创建和合并到main，绕过develop（尽管修复后也与develop同步）。它包含最少的更改，存在时间最短。如果feature或release可以推迟到下一个周期，热修复分支则不能。

对于移动开发，这一区别尤为重要：App Store和Google Play允许补丁版本与主要版本分开发布。热修复分支确保了补丁发布不与未完成功能混合的流程。

使用Hotfix时的常见错误

错误在使用热修复分支时可能抵消紧急修复的优势。让我们看一下使用Git Flow的团队中五个最常见的问题。

• 从develop创建热修复分支 — 如果从develop创建热修复分支，未完成的功能可能混入补丁。热修复分支只能从main创建，以确保修复只包含稳定代码。
• 一个热修复分支中包含多个修复 — 每个修复应在单独的热修复分支中。将多个错误混合在一个分支中使代码审核复杂化，增加回归风险，并在需要时难以回滚。
• 跳过合并到develop — 如果热修复分支未合并到develop，修复将在下次发布中丢失。团队会发现相同的错误再次出现，并不得不重新修复。
• 版本标签不正确 — 热修复分支应获得补丁增量（v2.3.0 → v2.3.1），而非次要（v2.4.0）或主要（v3.0.0）。违反语义版本规范会破坏构建系统并混淆用户。
• 缺少CI检查 — 即使是紧急热修复分支也应通过自动化测试。跳过CI会增加引入新错误的风险。建议为热修复分支设置单独的流水线，并加快检查速度。

这些错误中的每一个都会导致补丁发布延迟或在生产环境中出现新问题。团队应在CONTRIBUTING.md中确立热修复分支的工作规则，并通过CI/CD检查实现自动化。