问：

git分支管理中，master、develop、release、feature、hotfix分别有什么用，是怎么管理的?

答：

这是一个非常经典的 Git Flow 工作流问题。你提到的这 5 种分支，构成了一个规范且稳定的版本管理模型，非常适合需要长期维护、有明确发布周期的项目。

下面我会用“一句话定位 + 具体作用 + 管理流程”的方式逐一说明，最后再总结它们之间如何流转。

1. master (或 main)：生产线上的成品仓库

• 一句话定位：永远可发布的稳定版本。
• 具体作用：只存放对外正式发布的代码。每一次提交到 master 都对应一个线上版本（比如 v1.0, v1.1），通常会打上对应的 tag（标签）。
• 怎么管理：
  • 禁止直接在 master 上提交代码。
  • 唯一来源：只能从 release 或 hotfix 分支合并进来。
  • 合并后立即打上版本号标签，用于回滚或追溯。

2. develop：生产线的装配车间

• 一句话定位：日常开发的主集成分支。
• 具体作用：汇集所有已经开发完成、但尚未计划正式发布的新功能。这是团队协作的“枢纽”，包含了下一个版本的全部代码。
• 怎么管理：
  • 从 master 分支创建出来，是整个项目的“开发基线”。
  • 来源：所有 feature 分支完成后，都合并回 develop。
  • 去向：当 develop 上的功能积累到可以发布时，就从它拉出一个 release 分支。
  • 稳定性：要求基本可用（通过单元测试、集成测试），但不是绝对无Bug。

3. feature：具体零件生产线

• 一句话定位：开发单个新功能的临时分支。
• 具体作用：用于开发一个新功能、一个需求或一个重构任务。避免不稳定的代码影响 develop。
• 怎么管理：
  • 从 develop 拉出：git checkout -b feature/user-login develop
  • 命名：通常用 feature/功能名，如 feature/shopping-cart。
  • 生命周期短：功能开发并自测完成后，合并回 develop，然后立即删除该 feature 分支。

4. release：出厂前的质检站

• 一句话定位：准备发布的分支，用于最后的打磨。
• 具体作用：当 develop 已经包含下一期要发布的所有功能后，拉出 release 分支。在这里只做最后的小Bug修复、文档生成、版本号修改，绝对不再增加新功能。
• 怎么管理：
  • 从 develop 拉出：git checkout -b release/1.2.0 develop
  • 生命周期：
    1. 在 release 上修修补补，打出的问题修复可以同步合并回 develop（避免 develop 遗漏修复）。
    2. 质检通过后，将 release 合并到 master，并打上版本标签。
    3. 同时合并回 develop（确保 develop 也有这些最终修改）。
    4. 删除 release 分支。

5. hotfix：生产线的紧急修理工

• 一句话定位：紧急修复线上严重Bug。
• 具体作用：当线上 master 版本发现致命问题（如崩溃、支付失败）时，直接从 master 拉出，快速修复，绕过正常的开发流程。
• 怎么管理：
  • 从 master 拉出：git checkout -b hotfix/critical-bug master
  • 紧急流程：
    1. 修复并测试通过。
    2. 立即合并到 master，打上新的补丁版本标签（如 v1.0.1）。
    3. 同时必须合并回 develop（否则下次发布时Bug会重现）。
    4. 如果此时有 release 分支存在，也要合并到 release。
    5. 删除 hotfix 分支。

一个完整的工作流例子（帮助你形象理解）

假设你的项目版本是 v1.0.0：

1. 日常开发：程序员小A创建 feature/login 从 develop，开发完成后合并回 develop。
2. 准备发布：产品说“下周发 v1.1.0”。你从 develop 切出 release/1.1.0。小B在里面修改文档、修复一个UI小错位。
3. 紧急线上事故：就在这个节骨眼，v1.0.0 线上版本发现“用户无法登录”（严重Bug）。
   • 你立即从 master (对应 v1.0.0) 切出 hotfix/login-fix。
   • 修复后，合并到 master，打上 v1.0.1 标签。
   • 关键步骤：也把这个修复合并到 develop 和 当前存在的 release/1.1.0 分支。
4. 继续发布：release/1.1.0 测试通过后，合并到 master，打上 v1.1.0 标签。
5. 清理：删除 release/1.1.0 和 hotfix/login-fix 分支。

总结表

这个模型适合有固定发布计划（如双周或月度发版）的项目。如果是持续交付、每天发布多次的项目，可能会觉得它太重。那类项目更适合 GitHub Flow（只有 main + 短暂的 feature 分支）。