Git使用规范

  摘要  

        本文主要讲解Git 提交需遵循相应规范。Pull Request 方面，一个 PR 专注一件事。信息填写中，Title 分仅含一个 commit 和多个 commit 的情况；Content 也有要求。还有其它规范，如连接 issue，pr 完成后要妥善处理，以保证代码提交的高效与规范。

        开发统一使用git进行版本管理，使用git submodule实现代码模块化。在使用git进行提交和push等操作时需要遵循以下规范。

一、提交规范

1. 禁止提交到master分支、develop分支和其他稳定版本分支。

2. 一个独立的操作应该checkout为一个独立的分支，避免在一个分支里进行不相关的操作。

3. 提交信息要简明扼要，描述清楚操作内容。

提交信息模版:

<操作>(模块): <提交说明>

<详细说明>

其中, <操作>,模块,提交说明为必填且要描述清楚本次提交的目的。

错误示例:

fix(设备管理): 修复bug

正确示例:

fix(设备管理): 修复设备上线状态未同步的问题

操作必须为以下选项:

操作	含义
feat	新的功能
fix	修复bug
docs	文档相关
style	代码格式调整
refactor	代码重构,非bug修复或新的功能。
perf	性能优化
test	测试相关
build	构建相关
ci	CI相关
chore	无关紧要的变更
revert	回退提交

使用Idea时,建议安装 Git Commit Templatehttps://plugins.jetbrains.com/plugin/9861-git-commit-template 插件。在提交时:

也可以下载通灵义码：然后再提交代码的时候只需要动动手指，也能生成符合要求的git信息

二、Pull Request规范

2.1 概述

pull request（以下用pr代称） 需要严格遵循以下原则：

• 一个 pr 只围绕一件事

• 信息填写规范

• 其它规范

• pr完成后处理

2.2 一个PR只围绕一件事

一个 pr 应该只负责一件事，这遵循设计模式中的单一职责原则

如何定义一件事：

• 处理了一个 issue

• 解决了一个bug

• 新增了一个组件或功能

• 重构代码实现了某一个目的

一个 pr 可以包含多个 commit，但要注意尺度，保证 pr 不要过大

2.3 信息填写

2.3.1 Title

1.Pr 仅包含一个 commit

        直接使用 Github 默认填写的信息，即 Title 为 commit msg 的 subject 部分，Content 为 commit msg 的 body 部分

2.Pr 包含多个 commit

描述清楚这个 Pr 所做的事情，格式：[名词]+动词+名词+[形容词]+[名词]

例如：

• 修复 Collapse 组件无法展开的问题

• Collapse 组件添加 top 属性

• 新增 Message 组件

• 删除 Message 组件 color 属性

• 修改 Message 组件 top 属性单位为 rpx

注意英文单词左右添加一个空格方便阅读

动词建议从下列选项中选取：

• 新增（组件、属性、API）

• 修改

• 修正

• 删除

2.3.2 Content

        如果 title 已经描述清楚了此次 pr 的目的，则 Content 可以留空，否则应该对此次 pr 进行详细的描述.

2.4 其它规范

连接 issue

如果这个 pr 解决了某个 issue 提出的 bug 或者 feature，则应在 pr 中将此 issue 关联起来

在 pr 描述中 使用如下关键字可将 issue 关联起来：

• close

• closes

• closed

• fix

• fixes

• fixed

• resolve

• resolves

• resolved

示例： close #756

然后在下图中设置关联issue：

关联 issue 的好处：

• 可以在 issue 界面快速跳转到这个 pr，查看修复的情况
• 在该 pr 被合并进 master 分支后，对应 issue 会被自动 close。所以连接了 pr 的 issue 不需要手动 close

pr完成后处理

       每一个PR被merged（合并）后，应删除提交的临时分支，避免仓库在处理大量pr后，残留大量分支。

什么问题都可以评论区留言，看见都会回复的

如果你觉得本篇文章对你有所帮助的，把“文章有帮助的”打在评论区

多多支持吧！！！

点赞加藏评论，是对小编莫大的肯定。抱拳了！