Git规范及基础知识

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。

你可能感兴趣的:(git,git)