Git 是目前最流行的源代码管理工具。 为了能够科学有序、简单可靠地维护项目的代码仓库和历史版本，基于目前主流、成熟的Git工作流形式，考虑项目和团队的实际情况，编写此规范；
希望同时可以提升开发团队日常工作的效率和质量，使每个人能够熟悉标准化的合作方式，增强团队的凝聚力和面对复杂场景的处理能力；
约定
分支管理
1. master
命名：master
永久分支；
用于记录已上线的稳定代码 ；
通过合并release分支获取提交；
2. release
命名：release
永久分支；
用于待上线版本代码的合并、测试和修复；
接受两种代码提交：
- 合并次级开发分支develop上已通过测试并确认即将发版的提交
- 临时修复已上线版本bug的提交；
确定代码要上线发版后，将代码合并到master分支；
3. develop
命名：dev_branch_name
长期分支；
用于项目主要业务需求的开发、测试和bug修改；
根据业务需求任务线的划分决定此类分支的数量；
根据上线时间等因素决定分支建立时的父节点来自master还是已经存在的develop分支；
在通过测试并确认将要上线后，将代码合并到release分支，任务线结束后删除此分支；
4. feature
命名：feat_branch_name
临时分支；
用于开发实验性或小任务量的业务模块，根据需要基于master或相关develop分支创建；
开发完成后合并到release或对应的develop分支，并删除此feature分支；
5. fixbug
命名：fix_branch_name
临时分支;
用于线上版本bug的修复，基于master创建；
修复结束后合并到release分支，然后删除此分支；
常见任务
- 增加新功能
(dev)$: git checkout -b feature/xxx # 从dev建立特性分支
(feature/xxx)$: blabla # 开发
(feature/xxx)$: git add xxx
(feature/xxx)$: git commit -m 'commit comment'
(dev)$: git merge feature/xxx --no-ff # 把特性分支合并到dev
- 修复紧急bug
(master)$: git checkout -b hotfix/xxx # 从master建立hotfix分支
(hotfix/xxx)$: blabla # 开发
(hotfix/xxx)$: git add xxx
(hotfix/xxx)$: git commit -m 'commit comment'
(master)$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到master，并上线到生产环境
(dev)$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到dev，同步代码
- 测试环境代码
(release)$: git merge dev --no-ff # 把dev分支合并到release，然后在测试环境拉取并测试
- 生产环境上线
(master)$: git merge testing --no-ff # 把testing测试好的代码合并到master，运维人员操作
(master)$: git tag -a v0.1 -m '部署包版本名' #给版本命名，打Tag
合作的流程
直线段表示从父节点新建分支，曲线段表示合并操作；
- 上线版本的维护流程
- 日常开发测试的流程
提交信息
type：[scope：] subject [#index]
// 空行
[description]
-
type
说明本次代码提交的类型，使用以下几种前缀表示：merge 合并其他分支的代码；
**dev **业务或功能模块的阶段性提交；
**fix **修复测试流程中发现的bug，或开发过程中发现的过去的bug（测试中的bug使用dev前缀）；refactor 对代码进行重构优化，没有增加新功能或者修复bug；
**build **改变build.gradle等构建系统的文件内容，改变项目的依赖库、调试工具等；
**test_on **为了测试而改变了某些代码逻辑或环境配置；
**test_off **还原为了测试而改变的代码逻辑或环境配置；
scope
本次提交涉及的代码或业务功能的范围，与后面内容用冒号隔开;subject
本次提交的概要说明；
除了fix类型的提交以外应该使用祈使句，简要明确地表达清楚提交的内容，结尾无需添加标点；bugIndex
需求、任务、bug编号，当此提交是用来解决某个禅道对应的任务时，需要标明对应的编号；空行
用于分隔提交的标题和详细内容；description
用于记录一些细节，例如标题中没能说清楚的任务细节，需要记录的重难点逻辑或更新；
仓库的维护
分支操作权限
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
