git 协作规范

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分支的操作由开发者与同一任务线的组员沟通后执行；
本地分支根据个人需要建立，不做限制；
推送到服务器的分支必须符合命名规范，在分支任务结束后及时删除；

新建分支场景

1. 开始新业务模块的开发任务；
2. 同一任务线中的内容计划为分批次发布到生产环境；

例如任务分为一期和二期上线，一期开发完成并开始测试，为了不影响进度，在一期测试过程中同时需要进行二期的开发。由于二期的开发需要基于一期，并且需要保证一期可以脱离二期进行测试和上线，所以需要以一期为基础新建二期的分支。

版本发布后在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

附：一些有价值的参考

分享一份小团队的 Git 协作规范

一个成功的分支模型（中英文对照）

Git分支开发规范分享

GitPro 3.4：分支工作流介绍

GitPro 5.2：向一个项目做贡献

Commit提交指南