GitFlow内部规范
2019-07-19 本文已影响0人
GhostDou
图片.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：
- 有bug：见5.1
- 无bug：发布线上。
2、 develop分支：
- 从master-haier中继承一个分支命名为：develop-haier
- 每次master-haier有更新，都合并到：develop-haier分支。
3、 feature分支：
- 从develop-haier中fork一个分支命名：ft-addMenu。
- 添加菜单功能开发完成后，测试人员对ft-addMenu分支进行测试。
- 有bug：见5.3
- 无bug：合并到develop-haier，删除ft-addMenu分支。
4、 realease分支：
- 在ft-addMenu等功能合并到develop-haier后，从develop-haier中fork一个分支，命名为：realease-haier-v0.1。
- 内网测试在此分支上进行。
- 有bug：见5.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冲突
