为什么遵守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-时间-作者-原因
用几个小时来制定计划，可以节省几周的编程时间。—— 匿名