企业官网建设流程全解析

一、Git Flow分支管理模型（又称：Git Flow工作流）

1.1 核心分支

我们采用Git Flow工作流，主要包含以下两个贯穿整个项目生命周期的核心分支：

• master / main：生产环境主干分支，简称：主分支，始终保持稳定可发布状态
  • 作用：存放稳定、可随时部署到生产环境的代码
  • 特点：
    • 不允许直接在此分支上开发，仅允许通过release或hotfix分支合并
    • 分支上的每一个提交都对应一个正式的发布版本
    • 通常会被打上版本标签（如v1.0.0,v1.0.1）
• develop：集成开发分支，简称：开发分支，包含最新完成的功能和修复
  • 作用：存放最新开发成果的集成分支，是功能开发的集线器。
  • 特点：
    • 当develop分支上的代码达到稳定状态并准备发布时，会合并到主分支
    • 所有feature分支和release分支都从develop分支拉取
    • 始终保持代码可测试状态

1.2 辅助/临时 分支

上述分支是为了完成特定任务而创建的，任务完成后会被合并并删除

1.3 详细描述

• master主分支，也是用于部署生产环境的分支，需要确保master分支稳定性。master分支一般由release以及hotfix分支合并，任何时间都不能直接修改代码。
• develop开发分支，始终保持最新完成以及bug修复后的代码，用于前后端联调。一般开发的新功能时，feature分支都是基于develop分支创建的。
• feature开发新功能时，以develop为基础创建feature分支。分支命名时以feature/开头，后面可以加上开发的功能模块，命名示例：feature/user_module、feature/cart_module
  • 作用：开发新功能
  • 生命周期：
    • 从develop分支拉取。
    • 开发完成后，合并回develop分支。
    • 合并后，该功能分支通常被删除。
• release预发布分支（预上线分支），UAT测试阶段使用。一般由develop分支合并，不建议在此分支上直接修改代码。
  • 作用：为发布新版本做准备。在此分支上只做Bug修复、生成版本号、整理文档等发布准备工作，不再添加新功能。
  • 生命周期：
    • 当develop分支的功能足够进行一次发布时，从develop拉出release分支。
    • 在此分支上进行最后的测试和修复。
    • 准备就绪后，将release分支合并到主分支并打上版本标签。
    • 同时，还必须合并回develop分支，因为release分支上的修复可能在develop分支上不存在。
• hotfix线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支。修复完成后，需要合并到master分支和develop分支。
  • 作用：快速修复生产环境(master分支)上的紧急Bug
  • 生命周期：
    • 从master分支上出现 Bug 的提交点（通常是最近的标签）拉取。
    • 修复完成后，合并回master分支并打上新的版本标签（如v1.0.1）。
    • 同时，还必须合并回develop分支，确保修复在后续开发中也生效。

1.4 总体概述（图示）

二、软件环境管理规范

三、环境与分支映射

四、Git提交规范详解

4.1 提交类型速查表

4.2 提交格式要求

1. 标题格式：

   [类型] 简短描述（不超过50字符）

   • 类型使用小写英文
   • 描述使用现在时态
   • 不加句号结尾
2. 正文内容（可选）：
   • 空一行后补充详细说明
   • 解释修改原因和影响范围
   • 可包含相关issue链接
3. 优秀示例：

   [feat] 实现用户个人中心基础布局 新增以下组件： - 个人信息卡片 - 订单概览模块 - 地址管理入口 关联需求：#PROJ-123

五、最佳实践指南

5.1 单次提交注意事项

1. 提交问题必须为同一类别
2. 提交问题不要超过3个
3. 发现不规范提交可使用：

   gitcommit--amend-m"[提交类型] 新的提交信息"

   或者重新提交一次：

   gitreset--hardHEAD

5.2 工作流示例

1. 新功能开发：

   gitcheckout developgitpullgitcheckout-bfeature/user_profile# 开发完成后...gitcommit-m"[feat] 新增用户个人主页"gitpush origin feature/user_profile

2. 紧急修复：

   gitcheckout mastergitpullgitcheckout-bhotfix/payment_bug# 修复后...gitcommit-m"[fix] 解决支付接口超时问题"gitcheckout mastergitmerge hotfix/payment_buggitpush

5.3 版本发布流程

1. 从develop创建release分支
2. 在release分支进行最终测试
3. 合并到master并打 tag
4. 同步回develop分支

六、规范的价值

1. 提升可读性：通过提交信息快速理解变更意图
2. 自动化支持：便于生成CHANGELOG和版本说明
3. 高效协作：降低团队沟通成本
4. 精准回溯：方便定位问题和回滚变更

提示：建议团队使用Git钩子(pre-commit)或CI流程自动校验提交信息格式，确保规范执行一致性。

通过遵循这套规范，团队可以建立清晰可追溯的代码变更历史，大幅提升协作效率和代码质量。刚开始可能需要适应，但形成习惯后将显著改善开发体验。