GitFlow内部规范

http://Git工作流

图片.png

主分支：

• 命名： master-xxx
• 意义： 是发布到线上的代码版本，在主分支上会打上对应的版本号标签
• 维护者： 项目的主程、软件组长、专门维护线上版本人员
• 数量： 理论上只有一个，如果该项目面向多个渠道独立发布的，那就创建多个master

develop分支

• 命名： develop-xxx
• 意义： 团队开发合并和fork主要以此分支为准，开发过程中需要经常对develop进行合并
• 维护者： 如果有代码评审机制，那么在发送develop合并feature分支时，应该做代码评审。 维护者是整个开发团队。
• 数量： 与master分支对应

feature分支

• 命名： ft-xxx
• 意义： 团队成员开发具体需求时，需要从develop fork出一个特性分支，专门用来开发对应功能需求。 如果功能完成，测试人员可以针对该分支进行单独的功能测试，在禅道的任务中需要添加 的开发分支 就是这个特性分支
• 维护者： 当前开发此功能的研发人员

realease分支：

• 命名： release-xxx-vxxx
• 意义： 当一个迭代需要完成的功能已经合并到develop， 确定要对这些功能进行发布，从develop中fork出realease分支，中间xxx与master和develop的后缀对应，后面是版本号。
• 维护者：研发团队
• 使用： 内网测试是建立在此分支上的，release分支创建完成后不再接受功能级别的合并，仅支持测试出现的bug修复的合并。当测试完全通过后，与master合并，建立版本tag，准备发布。
• 合并规则： fix分支、feature分支、develop分支

hotfix分支：

• 命名：fix-{bug编号}
• 意义：用于对线上的bug的修复或测试版本的bug修复
• 维护：对应开发人员
• 使用：bug的修复可以在feature分支中进行，如果是迭代周期内的bug推荐使用feature修复，并与develp和对应的release分支合并。如果是线上的bug，那就从master分支fork出release分支和fix分支，使用fix进行修复，测试通过后，fix分支可以在之后的时间删除

---

例子

假设haier项目中增加一个添加菜单功能，版本号为0.1，禅道bug编号为4192.

1、主分支：

• 命名为master-haier：

1. 有bug：见5.1
2. 无bug：发布线上。

2、 develop分支：

• 从master-haier中继承一个分支命名为：develop-haier
• 每次master-haier有更新，都合并到：develop-haier分支。

3、 feature分支：

• 从develop-haier中fork一个分支命名：ft-addMenu。
• 添加菜单功能开发完成后，测试人员对ft-addMenu分支进行测试。

1. 有bug：见5.3
2. 无bug：合并到develop-haier，删除ft-addMenu分支。

4、 realease分支：

• 在ft-addMenu等功能合并到develop-haier后，从develop-haier中fork一个分支，命名为：realease-haier-v0.1。
• 内网测试在此分支上进行。

1. 有bug：见5.2
2. 无bug：合并到master-haier上，删除realease-haier-v0.1分支。

5、 hotfix分支：

• 命名规则：fix-4192。

5.1 线上bug：

• master-haier中fork出realease-haier-v0.1和fix-4192分支，fix-4192修复后合并至realease-haier-v0.1，进行内网测试。内网测试通过后，realease-haier-v0.1合并到master-haier上，发布线上。

5.2 内网测试bug：

• 建立fix-4192分支，修复后合并到realease-haier-v0.1。

5.3 feature bug：

• 在ft-haier上建立分支fix-4192分支，修复后合并至ft-haier分支。

---

开发记录

项目代码中建立gitbranch.md 文件，用来记录每次人员开发对分支的使用，特别的feature分支，需要经常更新

## master分支：
- master-main ： 云平台软件的主分支


## develop分支：
- develop： 云平台软件的主开发分支


## feature分支：
- ft-wall-rotateinfo: xxx 墙体旋转信息与ruler冲突