Git版本管理及使用规范

  git是目前为止版本管理的最常用工具之一，利用git的功能，可以很容易的实现版本的发布和留档，让原本杂乱的版本管理问题变得较为简单。

Git分支管理和常用流程

Git的常用分支包括：tag(git的功能，并不是真正的分支)、master、hotfix、bugfix、release、develop、feature

常用的合并流程如下图：

修改原则：能改的都是个人分支，多人协调的都是被管控的管理分支

分支简介

• tag：发布上线分支。实际上tag是一个gitlab的功能，在产品上线的时候基于主分支打tag，tag号一般为版本号，主要目的是为了留存和线上一模一样的代码环境，以备紧急时可以恢复现场。
• master：主干分支。有且仅有一个，除项目负责人外其他开发人员不得向 master 分支合并内容。只容许将已经测试完成的功能或者紧急修复的bug进行合入，以便进行打tag发版本。
• hotfix：紧急线上 bug 修复分支。紧急即需要立刻尽快去处理发布上线（自 master 拉取）, 直接进行测试及上线。
• bugfix：非紧急上线的 bug 修复分支。 如非当天上线即使用 bugfix 进行命名（自 master 拉取） , 直接进行测试及上线。
• release：预发布分支。作为提测及上线分支，release是发布正式版本之前（即合并到 master 分支之前），需要有一个预发布的版本进行测试，一般是转测给专门测试人员的转测分支。
• develop：主开发分支。存有确定性的所有功能（上线和未上线）, 作为开发环境共有的部署分支。该分支一般不容许个人直接合入，合入前需要进行代码review。
• feature：功能开发分支，feature 是为了开发后续版本的功能，从 develop 分支拉取出来的。开发完成稳定后，要再并入 develop 分支。在实际中，一般feature分支也会进行代码合入保护，由开发特性的组长进行负责，合入时要进行代码review工作。
• 个人分支：每个开发人员自己的开发分支，是实际开发中最多的项目分支，该分支的内容由每一位开发人员进行自行合入，开发完成后，根据开发的内容合入feature或者develop分支，合入时一般进行代码review工作。

命名规则

hotfix：hotfix_{功能}，如 hotfix_providerLose。
bugfix：bugfix_{功能}年月日，如 bugfix_pubMsg_20210701。
release：release{功能}年月日，如 release_pubMsg_20210701。
feature：feature{功能}_年月日，如 feature_pubMsg_20210701。

分支管理

• 上线完成之后, 提交申请进行master的合并处理, 打 Tag 维护（审核人员 / Leader）
• 相关分支创建人, 删除对应上线功能 feature / release / bugfix 分支

Git代码提交规约

• 代码提交时，在commit中写清楚完成了哪些内容
• 在进行合入develop或者feature时，在合入的Merge request中写清楚方案和实现思路，方便代码review
• 理论上一次提交仅包含一个功能修改，如功能过大，需要注明功能的完成进度。若一次提交有多个功能修改，则每个功能提交描述作为单独的一行。

代码提交流程

1、代码修改完成后，需先进行编码规范检查，注释检查，单元测试等操作。
2、测试通过后提交到本地，检查提交文件是否正确，有无遗漏文件，添加相关说明。
3、拉取服务器的代码，检查代码合并结果，若有冲突则找相关人员解决冲突。解决冲突后，重新编译测试代码，测试成功后提交本地代码。
4、推送代码到服务器。
5、提交merge request，提醒项目组成员进行代码review，完成后负责人合入分支