Git分支管理使用规范规约


为什么遵守git分支管理使用规范规约?

    由于团队早期使用git管理版本迭代较为混乱,没有一个合适的规范来制约。为提高团队开发效率,减少不必要的开发成本,特此制定该规范规约。

怎么做?

Git分支的定义:

Master

什么情况下使用:发布正式稳定版本

主分支,主要用来版本发布。

Develop

日常开发分支,该分支正常保存了开发的最新代码。

LocalFeature

在本地开发的新功能特性

LocalBug

在本地修复bug和优化重构

Release

Release分支是为新产品的发布做准备的。可以认为是 master 分支的未测试版,比如说某一期的功能全部开发完成,那么就将 develop分支合并到 release 分支,测试没有问题并且到了发布日期就合并到 master 分支,进行发布。

它允许我们在最后时刻做一些细小的修改。他们允许小bugs的修改和准备发布元数据(版本号,开发时间等等)。

 

Hotfix

线上bug及问题修复的分支。

Git规范要求

命名规范

分支命名规范

分支名称-作者-需求(特性功能、bug)Id (全小写)

例:

Dev-feature-user-featureId

Dev-bug-user-bugId

Hotfix-user-hotfixId

Release-feature-user-featureId

Release-bug-user-bugId

示例:Dev- feature -user-500695443

Commit提交规范

Commit的描述清晰明了,时间-作者-(feature、bug)Id-描述

示例:2019-7-8-13-34-user-500695443——【APP】工程施工上传进度不限10条的问题已成功解决。

版本号

1(大功能模块增加更新).1(小功能增加更新).1(bug修复)-rc

    上级版本变动,下级版本清零

 

Develop分支

本地开发的分支

Feature分支

  • 分支来源:develop
  • 最后合并:develop

 

  • 严禁开发新功能时修改bug,发现错误务必切到bug分支进行修改
  • 每天下午5点左右统一提交代码,解决合并代码时可能有的冲突
  • 每天早上编码前第一件事是拉取仓库代码

Bug分支

  • 分支来源:develop
  • 最后合并:develop

修复期间,不允许开发新功能特性,Bug解决并通过测试了才能合并到develop分支

 

Release分支

  • 分支来源:develop
  • 最后合并:masterdevelop

用来上线新发布的版本,新功能特性的预览发布。

bug修复和紧急需求开发完成及时提交到develop分支上,测试无问题后发布到master上。

develop分支创建新的Release分支的关键时刻是develop分支达到了发布的理想状态。至少所有这次要发布的features必须在这个点及时合并到develop分支。

 

对于所有未来准备发布的features必须等到Release分支创建以后再合并。

 

对于紧急上线需求则可在上面开发,开发完成测试通过后上线到master和同步到develop分支。

 

Hotfix分支

  • 分支来源:master
  • 最后合并:masterdevelop

解决迫在眉睫的问题分支

解决后必须及时拉到develop分支上体现出来,更新时体现出版本号

 

其他问题

合并冲突问题

冲突代码的编写人员互相交流甄辨代码的取舍。

分支删除问题

完成了需求特性和bug修复后即可提交,通过测试后及时删除当前分支。

备份分支

Backup-branchName-时间-作者-原因

 

 

用几个小时来制定计划,可以节省几周的编程时间。—— 匿名

点赞

发表评论

电子邮件地址不会被公开。必填项已用 * 标注