项目版本管理和Git分支管理方案

一、团队协作

该模块对应岗位角色：项目经理

1.项目团队与职责

2.项目时间线与里程碑

3.风险评估与应对措施

4.跨团队同步会议（定期）

跨团队同步会议（双周)

5.版本升级决策树

是否涉及接口变更？
├─ 是 → 是否需要旧版本兼容？
│  ├─ 是 → 底座平台发布次版本（如2.1.0），同步维护旧版本
│  └─ 否 → 底座平台升级主版本（如3.0.0），通知项目方适配
└─ 否 → 直接发布修订版本（如2.0.1），项目方自动升级

6.边界明确与路标制定

a.功能边界划分

● 底座A平台 ：专注于提供通用的底层功能，如用户认证与授权框架、数据缓存机制、通用的数据库访问接口等。这些功能是 B、C、D 项目所共用的基础设施。
● B、C、D 项目 ：各自聚焦于自身的业务领域。例如，B 项目负责供应链管理，其功能包括采购流程管理、库存监控等；C 项目侧重于客户服务，有客户投诉处理、服务工单管理等功能；D 项目是针对市场推广的，包含营销活动策划、广告投放管理等。它们仅在必要时调用 底座A平台的功能，不涉及底座A平台核心功能的修改。

b.项目路标制定

b1、项目路标制定核心要素

b2. 路标表格模板

b3. 项目路标制定Demo

二、需求文档

该模块对应岗位角色：产品经理

需求拆分

对于项目资源包里面的多个需求进行细化拆分，如涉及多个开发团队，拆分不同团队的独立需求块

需求文档

这里主要是需求文档的书写规范。不能几个字或者三两句话片面带过，同时时输出对应的（需求原型）UE设计稿，细节性功能点必须描述出来。总的来说要体现以下几点：

a. 项目背景

如下所示案例：
随着 [行业趋势或公司业务发展情况]，为了 [阐述项目开展的目的，如提升业务效率、拓展市场份额、满足用户新需求等]，特启动本项目。

b. 项目目标

如下所示案例：
1.功能目标 ：实现 [主要功能 1]、[主要功能 2]…… 例如，打造一个具备在线预约、实时查询停车位、智能导航等功能的智能停车管理系统。
2.业务目标 ：在项目上线后 [具体时长] 内，提高 [相关业务指标，如业务办理效率提升 [X]%、用户满意度达到 [X]% 等]。

c. 功能模块

1.功能模块 ：

○ 模块 1 - 在线预约功能 ：用户可在系统中查看可预约的停车位信息，包括位置、时间段、价格等，并完成预约操作。
○ 模块 2 - 实时查询停车位功能 ：用户通过地图或列表形式，实时查看周边停车场的停车位空余情况。

d. 功能需求

如下所示案例：
1、在线预约功能
● 1.1、 用户注册与登录
○ 支持手机号、邮箱、第三方账号（微信、支付宝等）注册登录。
○ 登录后进入个人中心，可查看预约记录、个人信息等。
● 1.2、 停车位搜索与筛选
○ 用户可在搜索框输入目的地或停车场名称，系统显示匹配结果。
○ 提供筛选条件，如按价格区间、距离范围、停车场类型等筛选可预约停车位。
2、实时查询停车位功能
● 2.1、 地图展示
○ 在电子地图上标记各停车场位置，用户点击停车场图标可查看详情，包括总车位数、剩余车位数、车位使用率等。
● 2.2、 列表展示
○ 以列表形式展示附近停车场信息，包含停车场名称、距离、剩余车位数、收费标准等，用户可按距离、剩余车位数等进行排序。

e. 产品原型（UE）

○ 输出相应的UE原型

需求评审&澄清

拉通会议相应人员进行需求评审&澄清
参会人员：项目经理，产品，开发，测试，UI

三、开发阶段

该模块对应岗位角色：开发人员

需求文档梳理

根据需求梳理和

需求实现方案设计

输出需求实现方案
需求反串讲
对于负责的需求进行需求反串讲

代码分支版本管理

a.常规版本

Git工作流流程图说明1

Git工作流流程图说明2

a1.关键步骤说明

1. 初始状态：main分支是稳定版本（v1.0）
2. 并行创建：
   ■ 从main拉取devops-A分支（紫色）
   ■ 从main拉取devops-B分支（紫色）
3. 开发过程中：
   ■ 定期将main合并到devops-A（绿色箭头）
   ■ 定期将main合并到devops-B（绿色箭头）
4. 功能A上线：
   ■ devops-A合并回main形成新版本（v1.1）
5. 功能B继续开发：
   ■ 将包含A功能的main（v1.1）合并到devops-B
6. 功能B最终上线：
   ■ devops-B合并回main形成最终版本（v1.2）

a2.补充操作规范

1. 合并方向原则：
   ■ 开发阶段：只允许main→feature分支单向合并
   ■ 上线阶段：只允许feature→main单向合并
2. 冲突处理窗口，目前都是工具处理

 	   # 开发分支合并main时的标准操作
   git checkout devops-A
   git fetch origin
   git merge origin/main
   # 解决冲突后
   git push origin devops-A

3. 上线后清理历史分支

 	# 功能上线后删除对应分支
   git push origin --delete devops-A
   git branch -d devops-A

b.定制版本

新分支不会合入主分支（新分支独立发展）

b1.关键步骤说明

1、初始状态：main分支为稳定版本（v1.0）
2、并行创建：
○ devops-A（紫色）：常规功能分支
○ devops-B（橙色）：独立发展分支
3、开发阶段：
○ 两者都定期合并main分支更新
○ devops-A保持与main同步开发
4、上线阶段：
○ devops-A：合并回main形成v1.1
○ devops-B：直接部署到生产环境（不合并回main）
5、后续演进：
○ main分支继续作为主开发线
○ devops-B成为独立产品线持续演进

b2.补充操作规范

最佳实践建议：

1. 分支命名规范：
   ○ 临时分支：devops-{功能名}
   ○ 永久分支：product-{产品线名}
2. 分支命名规范：
   ○ 临时分支：devops-{功能名}
   ○ 永久分支：product-{产品线名}
3. 分叉式管理策略：
   ○ devops-A：临时性功能分支（生命周期短）
   ○ devops-B：永久性独立分支（生命周期长）
4. 合并策略差异：
   graph LR
   main --> devops-A
   main --> devops-B
   devops-A --> main
   devops-B -.-x main

需求版本发布流程

• 1、版本发测之前确保代码是线上最新稳定版本也已合并进当前发测分支内，
• 2、版本内容测试范围的评估：主要分为新增功能和影响功能
  

四、测试计划

该模块对应岗位角色：测试

● 测试部署检查清单和文档
● 测试报告的输出

五、上线部署

该模块对应岗位角色：运维

● 上线部署检查清单

六、项目验收

该模块对应岗位角色：产品经理

● 产品验收标准（需求文档中需要体现）
● 同步输出验收结论
● 输出产品使用手册

七、版本总结

该模块对应岗位角色：项目经理

● 拉会进行版本总结