为什么遵守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
-
最后合并:master和develop
用来上线新发布的版本,新功能特性的预览发布。
有bug修复和紧急需求开发完成及时提交到develop分支上,测试无问题后发布到master上。
从develop分支创建新的Release分支的关键时刻是develop分支达到了发布的理想状态。至少所有这次要发布的features必须在这个点及时合并到develop分支。
对于所有未来准备发布的features必须等到Release分支创建以后再合并。
对于紧急上线需求则可在上面开发,开发完成测试通过后上线到master和同步到develop分支。
Hotfix分支
-
分支来源:master
-
最后合并:master和develop
解决迫在眉睫的问题分支
解决后必须及时拉到develop分支上体现出来,更新时体现出版本号
其他问题
合并冲突问题
冲突代码的编写人员互相交流甄辨代码的取舍。
分支删除问题
完成了需求特性和bug修复后即可提交,通过测试后及时删除当前分支。
备份分支
Backup-branchName-时间-作者-原因
用几个小时来制定计划,可以节省几周的编程时间。—— 匿名