ios-development-guidelines/docs/ios/IGXE分支管理说明.md

前言

根据项目具体情况，使用简化版Gitflow工作流，移除release、hotfix分支，使用developer_version分支替代。

目的

实现软件开发过程不同操作的相互隔离，并将软件生命周期中的各类活动归并到不同的分支上。

分支介绍

master

• 定义：生产环境分支，存放稳定可靠的线上代码
• 作用：记录每一个正式发布版本，tag所在分支
• 合并关系：允许developer_version分支的合并

• 合并保护：是

  developer_version

• 定义：开发分支

• 作用：保持最新的开发代码

• 合并关系：允许feature分支的合并

• 生命周期：从新版本开发到正式上架APP Store，包含整个测试阶段

• 合并保护：是

  feature

• 定义：新功能分支

• 作用：独立的功能需求

• 合并关系：不允许任何分支合并

• 建立时机：需要开发新的功能

• 初始代码来源：developer_version最新commit

• 完成操作：合并至developer_version分支

• 合并保护：否

日常开发流程

• 任务划分完成后，每个成员新开一个feature分支，分支以自己姓名拼音命名，每个人在自己的feature分支上进行开发；
• 当feature开发完成后，登录Gitlab后台提交合并申请，等待代码合并审核通过后，拉取developer_verison覆盖本地feature,以保持代码同步；
• 在经过完备的测试且具备上线条件后，最后将developer_version合并到master上；
• 在master上根据版本号打上标签并推送到远程仓库；
• 完成新版本开发生命周期。

热修复流程

• 如果线上某一版本出现问题，根据tag找到对应的版本，新开一条developer_version，成员拉取developer_version覆盖本地的feature后进行开发，修复完成后，登录gitlab后台提交合并申请。

• 等测试验收通过后，再将developer_version合并回master分支，同时根据版本号打上标签并推送到远程仓库。

  图例

  

注意

• 远程仓库只存放两种分支
• 一个是master分支，存放线上（生产环境）版本，这个分支的代码总是可靠可用的；
• 另一个是develop_version分支，这个分支用于标记日常开发版本。
• feature 分支下可以有多个feature同时在开发，并不影响，feature最终是提交到develop_version分支上。 ----

Commit message格式

• 为了方便进行代码审核，每次commit的提交信息必须清晰明了，说明本次提交的目的。

• 格式如下：

  [type]desc
  

type：用来说明类型，常用的有以下几种：

• feature：完成新功能的开发
• fix：代码BUG的修复
• UI：样式的修改
• refactor：代码重构
• docs：文档
• chore：构建工具
• pods：引用

desc：用来简短描述此次的变动，描述只要简明易理解就好，没必要写很多.

案例

[feature]新增购物车功能
[fix]修复立即购买按钮闪退
[UI]饰品详情页UI完成
[refactor]网络基类重构
[docs]新增支付说明文档
[chore]增加打包自动化脚本
[pods]更新"AFNetworking"网络库

Gitlab合并请求路径