企业官网建设流程全解析

问：

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分支）。