美文网首页
git管理规范

git管理规范

作者: 涅槃快乐是金 | 来源:发表于2022-11-28 20:08 被阅读0次

1. 分支

分支 功能 生命周期 名称规则 分支操作流程 说明
master 归档分支 长期 master develop --mr--> master 主要用来归档,保留每个版本的 tag,不能被 push,变更只能通过 merge 或者 rebase
develop 回归分支 长期 develop feature --mr--> develop --create tag--> tag --mr--> master 主要用户回归测试,如果回归测试过程中发现bug,从 develop 创建 fix
feature 需求分支 临时 feature_{需求ID}_{版本日期} task --mr--> feature --mr--> develop 根据需求从 develop 创建,使用完之后合并到 develop 并且删除当前分支
task 任务分支 临时 task_{需求ID} user --mr--> task --mr--> feature 一个需求任务对应一个 task,同一个 需求下的 task 分支从属同一个 Feature 分支,task分支在单人开发项目中是可以被省略的
user 个人分支 临时 yourname/xxx code --pr--> task 个人开发分支

2. commit message

  1. 格式如下:

    <类型>[可选的作用域]: <描述>
    
    [可选的正文]
    
    [可选的脚注]
    
  2. 类型枚举

    # 主要type
    feat:     增加新功能
    fix:      修复bug
    
    # 特殊type
    docs:     只改动了文档相关的内容
    style:    不影响代码含义的改动,例如去掉空格、改变缩进、增删分号
    build:    构造工具的或者外部依赖的改动,例如webpack,npm
    refactor: 代码重构时使用
    revert:   执行git revert打印的message
    
    # 暂不使用type
    test:     添加测试或者修改现有测试
    perf:     提高性能的改动
    ci:       与CI(持续集成服务)有关的改动
    chore:    不修改src或者test的其余修改,例如构建过程或辅助工具的变动
    
  3. 项目中推荐使用 commitlintcommit message 执行强制校验,推荐使用如下配置文件

    module.exports = {
      extends: ['@commitlint/config-conventional'],
      rules: {
        'type-enum': [2, 'always', [
          'feat', 'fix', 'docs', 'style', 'refactor', 'test', 'chore', 'revert'
        ]],
        'subject-full-stop': [0, 'never'],
        'subject-case': [0, 'never']
      }
    }
    

3. code review

  1. cr 必要性

    • 代码,是设计理念落地的地方,是技术的呈现和根本。同学们可以在 review 过程中做到落地沟通,不再是空对空的讨论,可以在实际问题中产生思考的碰撞,互相学习,大家都掌握团队里积累出来最好的实践方式!

    • 在编码过程中可以提前发现不符合业务逻辑或者质量不高的代码

    • 高手可以直接指出新手代码中的问题,新手可以马上从高手的反馈中学习到好的实践,得到更快的成长

    • 更快地了解业务

    • 让团队规范得到执行

    • 培养先设计再开发的习惯

  2. cr 时机

    • 开发者写下第一行代码就需要提交对应的 pr 到对应的评审者

    • 按照功能粒度进行提交,复杂功能按天提交 pr

    • 评审者要在测试工作完成之前审核完对应的 pr

    • 建议: 单个 pr 不能超过 8 个 commit,复杂的功能需要提前告知评审者

  3. cr 谁来做

    • 多人合作开发的项目由负责人进行 cr

    • 单人项目可以找对应的业务负责人 或者 由对应的业务负责人指定人员进行 cr

    • 项目负责人编写的代码由其他相关的业务负责人进行 cr

  4. cr 做些什么

    • 代码是否很容易理解

    • 代码中是否有重复的地方

    • 代码是否容易测试和调试

    • 代码是否考虑到了非功能性需求,如性能、内存

    • 代码是否过于庞大

    • 代码格式是否遵循团队规范

4. CHANGELOG 规范

版本日志跟随每一个上线版本更新,统一到一个 CHANGELOG.md 文件中,通常需要包含以下内容

  • 当前版本的任务号

  • 当前版本干系人

  • 当前版本的时间节点

  • 当前版本的需求概要

相关文章

  • GIT 规范

    git 规范 git 规范一般包括两点:分支管理规范和 git commit 规范。 分支管理规范 一个项目可以创...

  • 规范

    1 工作流规范 1.1 git规范 1.1.1 分支管理规范 git版本管理中主要有以下几种类型的分支:maste...

  • git分支管理与使用规范

    git分支管理与使用规范 分支管理 flow git flow github flow gitlab flow f...

  • Git命令清单 + 一张图掌握Git

    Git命令清单Git远程操作详解Git使用规范流程Git分支管理一张图掌握Git

  • Web前端工程化

    规范化 工程结构规范 编码格式规范 前后端接口规范 文档书写规范 Git分支管理规范 Commit描述规范 交互设...

  • git管理规范

    1、(主分支)master ​ 线上分支:时刻保持与线上代码一致, 非必须尽量避免在master上修改提交代码...

  • Git管理规范

    仅作记录学习 原博地址:https://blog.51cto.com/wutengfei/2091616[http...

  • git管理规范

    1. 分支 分支功能生命周期名称规则分支操作流程说明master归档分支长期masterdevelop --mr-...

  • Git 速查

    常用 Git 命令清单 --阮一峰Git 使用规范流程 --阮一峰Git 工作流程 --阮一峰Git 分支管理策...

  • Java开发必备 Git 分支开发:规范指南及完全学会Git的2

    Git 是目前最流行的源代码管理工具。为规范开发,保持代码提交记录以及 git 分支结构清晰,方便后续维护,现规范...

网友评论

      本文标题:git管理规范

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