其他分享
首页 > 其他分享> > Git规范管理

Git规范管理

作者:互联网

一、背景​ 统一规范后,对于后面的一系列的开发过程由系统完成,从而提高研发效率,避免各种意外情况。   二、分支管理 master分支对应线上,系统上线时。 平时进行需求开发、线上bug修复(可以理解为特殊需求),大多数情况下都需要基于master分支拉取特性分支。 1.分支命名规范​:   支命名需要具备一定的可读性,“分支信息-名字简写”,分支信息应做到言简意赅,全英文描述,多个单词使用“-”进行连接。

2.分支类型概述

   每次需求开发,都从master拉自己的特性开发分支,进行本地开发和单元测试,通过后再merge到dev分支,发布dev环境进行联调和冒烟测试。​ 三、研发流程 1. master->个人特性开发分支->dev​   每次需求开发,都从master拉自己的特性开发分支,进行本地开发和单元测试,通过后再merge到dev分支,发布dev环境进行联调和冒烟测试。 2.test:个人特性开发分支->test​   冒烟通过后,转测试,先将远端test分支checkout到本地(保证最新代码),然后将个人特性分支merge到本地test分支,解决冲突后,再将本地test分支push到远端test。​   注:出现和别人代码冲突的,请第一时间咨询对应的开发同事,解决冲突,禁止暴力覆盖别人的代码​ 3.staging:个人特性开发分支->staging​   经测试验证通过后,转UAT,先将远端staging分支checkout到本地(保证最新代码),然后将个人特性分支merge到本地staging分支,解决冲突后,再将本地staging分支push到远端staging。​   注:staging分支上的代码是本次迭代需要上线的代码,如果不是,则不可出现在staging分支​   两两互相review​ 4.staging->master​   经UAT验证通过后,达到测试的上线标准后,将staging分支merge到master,在push到远端master。​   注:这样才能保证上线的代码和UAT验证通过的代码是一致的,减少再次回归的重复工作。 5.master->fix​   线上发现问题,需要修复的,从master分支checkout出fix-{xxx}分支,进行bug修复,修复完毕后,走上面1-4步的研发流程。​ ​6.master->tag​   发布上线完成后,打tag标记, 进行归档。​   ​四、commit 格式​
  1. 需求任务:story#xxx {内容}​
  1. bug任务:bug#xxx {内容}​

标签:Git,staging,管理,规范,merge,开发,master,test,分支
来源: https://www.cnblogs.com/czlong/p/16646121.html