本文内容全原创手打，希望大家可以喜欢，文末附上个人觉得有价值的参考。
为了能够科学有序、简单可靠地维护项目的代码仓库和历史版本，基于目前主流、成熟的Git工作流形式，考虑项目和团队的实际情况，编写此规范；
希望同时可以提升开发团队日常工作的效率和质量，使每个人能够熟悉标准化的合作方式，增强团队的凝聚力和面对复杂场景的处理能力；
分支类型的约定
master
命名：master
永久分支；
用于记录已上线的稳定代码 ；
通过合并release分支获取提交，通过tag等方式记录版本信息；
当master有了新的提交时将提交合并到所有develop分支；
release
命名：release
永久分支；
用于待上线版本代码的合并、测试和修复；
接受两种代码提交：合并次级开发分支develop上已通过测试并确认即将发版的提交、临时修复已上线版本bug的提交；
代码上线发版后，将代码合并到master分支；
develop
命名：dev_branch_name
长期分支；
用于项目主要业务需求的开发、测试和bug修改；
根据业务需求任务线的划分决定此类分支的数量，如跑团、直播、保险、公共；
根据上线时间等因素决定分支建立时的父节点来自master还是已经存在的develop分支；
在通过测试并确认将要上线后，将代码合并到release分支，任务线结束后删除此分支；
feature
命名：feat_branch_name
临时分支；
用于开发实验性或小任务量的业务模块，根据需要基于master或相关develop分支创建；
开发完成后合并到release或对应的develop分支，并删除此feature分支；
fixbug
命名：fix_branch_name
临时分支;
用于线上版本bug的修复，基于master创建；
修复结束后合并到release分支，然后删除此分支；
分支合作的流程
直线段表示从父节点新建分支，曲线段表示合并操作；
上线版本的维护流程
日常开发测试的流程
提交信息的格式
type ：[scope：] subject [#bugIndex]
// 空行
[description]
type
说明本次代码提交的类型，使用以下几种前缀表示：
merge 合并其他分支的代码；
**dev **业务或功能模块的阶段性提交；
**fix **修复测试流程中发现的bug，或开发过程中发现的过去的bug（测试中的bug使用dev前缀）；
refactor 对代码进行重构优化，没有增加新功能或者修复bug；
**build **改变build.gradle等构建系统的文件内容，改变项目的依赖库、调试工具等；
**test_on **为了测试而改变了某些代码逻辑或环境配置；
**test_off **还原为了测试而改变的代码逻辑或环境配置；
scope
本次提交涉及的代码或业务功能的范围，与后面内容用冒号隔开;
subject
本次提交的概要说明；
除了fix类型的提交以外应该使用祈使句，简要明确地表达清楚提交的内容，结尾无需添加标点；
bugIndex
JIRA上的bug编号，当此提交是用来解决某个JIRA上的bug时，必须在提交标题中标明，如 “ #1600”；
空行
用于分隔提交的标题和详细内容；
description
用于记录一些细节，例如标题中没能说清楚的任务细节，需要记录的重难点逻辑或更新；
示例
dev：设计改版：更新首页文案
dev：微服务-自助理赔：界面开发，逻辑优化
1，修正未勾选协议的弹窗时机
2，完成待上传资料的设计改版
dev：消息中心-保单签收：数据加载失败，未显示“点击加载”（娟）#1781
dev：泰爱牙：我的预约列表 #1622 #1633 #1721 #1722
fix：首页：banner加载延迟
merge：微服务一期优化
merge：release-v2.0.13
//注：此格式用于master合并release分支
build：更新gradle版本为3.4.1，修复产生的问题
build：更新依赖库：butternife，rxandroid
release：v2.0.13 优化运营体验
//注：此格式用于release
release：v2.0.11 跑团内容更新
1，修复多台机器间数据同步的问题
2，新增历史数据多天上传功能
3，支持界面外部打开，去账号小改
refactor：优化安装包大小
1，删除重复或无用的图片资源
2，移除不再使用的running_group模块
test_on：关闭人脸识别校验
test_off：打开人脸识别校验
版本仓库的维护
分支操作权限
release、master分支相关的操作由版本库的维护人员执行；
develop、fixbug分支的建立和删除由开发者与版本库的维护人员沟通后执行；
feature分支的操作由开发者与同一任务线的组员沟通后执行；
本地分支根据个人需要建立，不做限制；
推送到服务器的分支必须符合命名规范，在分支任务结束后及时删除；
新建分支场景
- 开始新业务模块的开发任务；
- 同一任务线中的内容计划为分批次发布到生产环境；
例如任务分为一期和二期上线，一期开发完成并开始测试，为了不影响进度，在一期测试过程中同时需要进行二期的开发。由于二期的开发需要基于一期，并且需要保证一期可以脱离二期进行测试和上线，所以需要以一期为基础新建二期的分支。
版本发布后在release分支上打标签，在master分支合并release
- 标签打在release分支用于打包发版的提交上，格式示例如下：
1 标签名：
v2.0.11
2 标签信息：
v2.0.11 跑团内容更新
1，修复多台机器间数据同步的问题
2，新增历史数据多天上传功能
3，支持界面外部打开，去账号
- master合并release，禁用快速前进，产生的新提交格式如下：
merge：release-v2.0.11 跑团内容更新
1，修复多台机器间数据同步的问题
2，新增历史数据多天上传功能
3，支持界面外部打开
维护人员的维护内容
检查各分支的建立是否符合规范，能否合理地满足业务需要；
检查服务器上的分支是否都在使用，清理没有价值的分支；
当develop分支开发任务结束后，将分支内容合并到release分支，对于不容易理解、处理的冲突必须与开发人员进行沟通后操作；
记录release分支对其他分支的每次合并，在合并的提交信息中说明合并的内容、遇到的问题等信息；
在新版本发布后将release合并到master；
在运营人员发布新版本后，通过tag等方式记录release分支发版的更新内容、版本号、待处理的bug、临时性的发布原因等信息，更新versionName和versionCode；
在每次master分支完成合并后，将合并内容更新到所有develop分支；
与产品运营人员交流合适的发版时机和可能存在的问题；
检查提交信息是否符合规范，与不符合规范的提交的所有者进行沟通；
根据日常应用情况不断完善此规范，补充一些常见问题的解决方法和Git使用技巧，如有必要还应补充一些概念或技术说明，供新手查阅学习；
需要注意的事项
每次新版本发布，在各开发分支合并主分支的代码（重要）
适度提交频率
将太多代码改动放到单独一个提交中，可能会使提交中包含多个业务或功能模块，过于耦合，从而增加了回顾历史的复杂度，增加了对提交进行合并、摘取、撤销等操作的难度；
提交过于频繁内容太少，例如在修改一个bug或完成一个小功能点时进行了多次提交，就是不必要的冗余提交；
应该尽量做到，小任务量的bug修复或功能点作为一个提交，大任务量的bug修复或功能点分阶段进行多次提交，争取保证每个提交的内容从业务角度或时间角度来说是独立的；
合并分支不采用快速前进
- 命令行：
git merge --no-ff
避免冗余提交 Merge remote-tracking branch ...A... into ...B...
- 命令行：
git pull --rebase
- AndroidStudio：
在pull时选择updateType为rebase：
