Git规范

作者: 095b62ead3cd | 来源:发表于2020-06-10 16:04 被阅读0次

    分支管理

    分支命名

    master 分支

    • master 为主分支,也是用于部署生产环境的分支,确保master分支稳定性
    • master 分支一般由develop以及hotfix分支合并,任何时间都不能直接修改代码

    develop 分支

    • develop 为开发分支,始终保持最新完成以及bug修复后的代码
    • 一般开发的新功能时,feature分支都是基于develop分支下创建的

    feature 分支

    • 开发新功能时,以develop为基础创建feature分支
    • 分支命名: feature/ 开头的为特性分支, 命名规则: feature/user_module、 feature/cart_module

    release分支

    • release 为预上线分支,发布提测阶段,会release分支代码为基准提测

    当有一组feature开发完成,首先会合并到develop分支,进入提测时,会创建release分支。
    如果测试过程中若存在bug需要修复,则直接由开发者在release分支修复并提交。
    当测试完成之后,合并release分支到master和develop分支,此时master为最新代码,用作上线。

    hotfix 分支

    • 分支命名: hotfix/ 开头的为修复分支,它的命名规则与 feature 分支类似
    • 线上出现紧急问题时,需要及时修复,以master分支为基线,创建hotfix分支,修复完成后,需要合并到master分支和develop分支

    常见任务

    增加新功能

    (dev)$: git checkout -b feature/xxx          
      # 从develop建立特性分支 (feature/xxx)$: blabla
     # 开发 (feature/xxx)
    $: git add xxx (feature/xxx)
    $: git commit -m 'commit comment' (dev)
    $: git merge feature/xxx --no-ff # 把特性分支合并到develop 
    

    修复紧急bug

    (master)$: git checkout -b hotfix/xxx         # 从master建立hotfix分支 (hotfix/xxx)
    $: blabla # 开发 (hotfix/xxx)$: git add xxx (hotfix/xxx)
    $: git commit -m 'commit comment' (master)
    $: git merge hotfix/xxx --no-ff # 把hotfix分支合并到master,并上线到生产环境 (develop)
    $: git merge hotfix/xxx --no-ff # 把hotfix分支合并到develop,同步代码 
    

    测试环境代码

    (release)$: git merge develop --no-ff # 把develop分支合并到release,然后在测试环境拉取并测试 
    

    生产环境上线

    (master)$: git merge testing --no-ff   # 把testing测试好的代码合并到master,运维人员操作 (master)$: git tag -a v0.1 -m '部署包版本名' #给版本命名,打Tag 
    

    二、Git提交信息规范

    当前业界应用的比较广泛的是 Angular Git Commit Guidelines

    1 介绍

    Git进行commit时都需要提交说明(commit message):

    Git commit -m  'hello world'
    

    -m参数就是用来指定commit message的

    commit message应该清晰明了,说明本次提交的目的。

    2 Commit message的格式

    Commit message应该包括三个部分:Header/Body/Footer。其中,Header是必需的,Body和Footer可以省略。

    <type>(<scope>): <subject>
    
    // 空一行
    
    <body>
    
    // 空一行
    
    <footer>
    
    

    不管是哪一个部分,任何一行都不得超过72个字符(或100个字符)。这是为了避免自动换行影响美观

    2.1 Header

    只有一行,包含三个字段,type(必须)、scope(可选)和subject(必须)

    (1)type

    用于说明commit的类别,只允许使用一下8个标识:

    1. feature:添加新功能
    2. fix:修补bug
    3. docs:仅仅修改了文档
    4. style:仅仅修改了空格、格式缩进、逗号等等,不改变代码逻辑
    5. refactor:重构(即不是新增功能,也不是修改bug的代码变动)
    6. test:增加测试用例
    7. performance: 增加代码进行性能测试
    8. chore:改变构建流程、或者增加依赖库、辅助工具等

    (2)scope

    用于说明commit影响的范围,比如数据层、控制层、视图层等,是项目不同而不同

    (3)subject

    是commit的简短描述,不超过50字符

    例如fix: array parsing issue when multiple spaces were contained in string.

    • 义动词开头,使用第一人称现在时(change,而不是changed)
    • 第一个字母小写
    • 结尾不加句号(.)

    2.2 Body

    是对本次commit的详细描述,可以分成多行:

    More detailed explanatory text,  if necessary.  Wrap it to 
    
    about 72 characters or so. 
    
    Further paragraphs come after blank lines.
    
    - Bullet points are okay, too
    
    - Use a hanging indent
    

    有两个注意点:

    1. 使用第一人称现在时
    2. 说明代码变动的动机,以及与以前行为的对比

    2.3 Footer

    只是用与两种情况

    (1) 不兼容变动

    如果当前代码与上一个版本不兼容,则Footer部分以BREAKING CHANGE开头,后面是变动的描述以及变动理由和迁移方法

    BREAKING CHANGE: isolate scope bindings definition has changed.
    
    To migrate the code follow the example below:
    
    Before:
    
    scope: {
    
    myAttr:  'attribute' ,
    
    }
    
    After:
    
    scope: {
    
    myAttr: '@',
    
    }
    
    The removed `inject` wasn't generaly useful  for directives so there should be no code using it.
    
    

    (2)关闭Issue

    如果当前commit针对某个issue,那么可以在Footer部分关闭这个issue

    Closes  #123,  #245,  #992
    
    

    2.4 Revert

    有一种特殊情况,如果当前commit用于撤销以前的commit,则必须以revert:开头,后面跟着被撤销的Commit的Header

    revert: feature(pencil): add  'graphiteWidth' option
    
    This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
    
    

    Body部分的格式是固定的,必须写成·This reverts commit ·

    Commitizen

    一个撰写合格的Commit message的工具

    安装:

    npm install -g commitizen
    
    

    然后,在项目目录里,运行下面的命令,使其支持 Angular 的 Commit message 格式。

    commitizen init cz-conventional-changelog --save --save-exact
    
    

    以后凡是用到 git commit 的命令,一律改为 git cz ,这时,就会出现选项,用来生成符合格式的Commit message。

    validate-commit-msg

    用于检查Node项目的Commit message是否符合格式,需要手动安装

    首先拷贝这个JS文件到代码库,命名为validate-commit-msg.js

    然后把这个脚本加入Git的Hook,在package.json中使用ghooks,把这个脚本加为commit-msg时运行

    "config" : {
    
    "ghooks" : {
    
    "commit-msg" :  "./validate-commit-msg.js"
    }
    }
    
    

    然后每次Git commit时脚本就会自动检查Commit message是否合格,不合格就会报错

    简单的示例

    
    feature: 新增分析师清理功能
    
    分析师清理功能,包括 
    
    1 . 查询分析师 
    
    2 . 分时段清理
    
    

    不包含正文的提交说明

    
    docs: correct spelling of CHANGELOG
    
    

    包含作用域的提交说明

    
    feature(lang): added polish language
    
    

    为fix编写的提交说明,包含可选的issue编号

    
    fix: minor typos in code
    
    see the issue  for  details on the typos fixed 
    
    fixes issue #12
    
    

    为什么使用约定式提交Commit message

    1. 自动化生成 CHANGELOG。
    2. 基于提交的类型,自动决定语义化的版本变更。
    3. 向同事、公众与其他利益关系人传达变化的性质。
    4. 触发构建和部署流程。
    5. 让人们更容易地探索结构化的提交历史,降低贡献项目的难度。

    参考

    相关文章

      网友评论

          本文标题:Git规范

          本文链接:https://www.haomeiwen.com/subject/onlptktx.html