Git仓库使用规范

在之前项目中制定的规范，在此记录一下，也方便他人借鉴。

分支模型#

分支模型采用主干开发的模型，为Release建立Tag或分支的风格：https://trunkbaseddevelopment.com/branch-for-release/

分支类型：

主干分支，即Git中的master分支，日常开发的代码都会合并到此分支 版本分支，与某个生产版本所对应的分支 分支使用规范：

开发中的代码直接提交到主干分支(master分支)，建议使用 rebase 的方式将本地代码与远程代码合并 开发中的版本BUG修复直接提交到主干分支(master分支) 版本发布时，在主干分支(master分支)上打 tag，tag 名称为对应的版本号 当发布的版本出现 BUG 需要修复时，按照下面流程进行

确定对应的版本分支是否存在，如不存在，则从版本对应的 tag 拉出对应的版本分支 确定 BUG 在当前开发版本中是否存在： 如当前开发版本中存在同样的 BUG，先在主干分支(master分支)上提交修复，然后将 commit cherry-pick 到对应的版本分支上 如当前开发版本中不存在 BUG，直接在对应的版本分支上修复 修复完成后，升级小版本号，并在版本分支上打 tag

代码提交规范#

一次提交只做一件事#

不要把不相干的代码提交在一个commit中，比如修改了2个BUG又实现了一个功能，应分成3个提交。

只做一件事的提交有助于cherry-pick到其它分支，同时也方便对于某个功能进行回滚。

使用REBASE，不要使用MERGE#

在每次pull代码时，必须使用rebase以保证git的提交历史是线性的。不要使用merge，不要使用merge，不要使用merge，重要的事情说3遍！！！

线性的提交历史有助于进行cherry-pick，我们在修复前场BUG时应先在master分支上修复，然后cherry-pick到对应的版本分支上。

Git Commit Message 格式#

提交代码时的message说明应遵循以下格式：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

其中 <type> 为本次提交的类型，分为：feat, fix, hotfix 其它可选类型有：style, test, refactor, build, ci, docs 增加新功能时使用feat, 修复BUG时使用fix，修改前场问题时使用hotfix

例如：

feat: 增加调度限流功能

可以选择通过 option scope 来描述相关模块或者BUG，例如：

feat(poc): 实现用例参数获取功能

或

fix(jira: SAF-671): 安全设备视角-选择全部虚拟靶机问题修复