Git规范
所有使用项目，必须严格按照规范操作，否则不予合并代码、提测、打包上线等后续操作。
基本要求
所有commit必须要有注释，内容必须按照注释格式严格执行，合理控制内容提交的颗粒度，一次commit含一个独立功能点，禁止一次提交涵盖多个功能项目，正确为每个项目设置提交用到的user.name信息，不可随意设置无法识别的信息。
版本号（tag）
版本号命名规则：主版本号.次版本号.修订版本号，（遵循github语义化版本命名规范），版本号仅标记master分支，用于标记某个可发布/回滚的版本代码，对master标记tag意味着该tag能发布到生产环境，对于master分支代码的每一次更新(合并)必须标记版本号，仅项目管理员有权限对master进行合并和标记版本号
项目权限
浏览者(Guest)只能浏览代码，无push、pull request等所有写权限 开发者(Developer)拥有浏览、push非主分支、提交pull request工单权限 管理员(Master)拥有建立和管理Git项目、合并分支和代码、给master打tag版本号等权限
分支使用
每个Git项目固定含有上述所有分支类型。主分支master和develop是保护分支，只能进行合并请求，均不可直接提交代码。
功能需求或常规Bug修复，请从develop拉取feature分支；线上紧急问题修复，请从master拉取hotfix分支。
代码提交
一个提交就代表解决一个问题 大问题适当地分解为多个小问题，以便每次小型提交都更易于理解
代码合并
将开发完毕的分支，拉取develop最新代码，merge并解决冲突后，之后在对应的feature分支创建并提交到develop分支，并自动触发merge request请求，然后进行code review，确认无误后再合并。
（每个merge request不要包含不相关的功能；merge request提交后需要及时跟踪动态，包括通过、打回等；该功能进入提测流程后，需删除之前的功能分支）
注释格式
每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。 其中，Header 是必需的，Body 和 Footer 可以省略。不管是哪一个部分，任何一行都不得超过72个字符。这是为了避免自动换行影响美观。
Header
Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。
type用于说明 commit 的类别，只允许使用下面7个标识。
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
subject是 commit 目的的简短描述，不超过50个字符。以动词开头，使用第一人称现在时，比如change，而不是changed或changes第一个字母小写结尾不加句号（.）
Body
Body 部分是对本次 commit 的详细描述，可以分成多行, 有两个注意点:
使用第一人称现在时，比如使用change而不是changed或changes;
应该说明代码变动的动机，以及与以前行为的对比;
Footer
Footer 部分只用于两种情况:
如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法;
如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue (Closes #123, #245, #992), GitHub这个功能很好用；
Revert
还有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header。