• Git使用规范指南

    文章目录

    Git使用规范指南

    前言

    由于最近写完代码之后，Git使用不规范被领导说了，所以最近通过阅读大量的相关博客快速学习Git使用规范，关于Git的相关基础知识，可以参考我的这篇文章：Git、Github、Gitee、GitLab学习笔记-CSDN博客

    PS：参考资料在文末，至此也十分感谢互联网上哪些无私分享知识的前辈，可能文中存在纰漏或者描述不当的地方，还请各位大佬能够告知博主，博主将不胜感激

    分支命名规范

    分支功能环境可访问
    master主分支，稳定版本pro是
    develop开发分支，最新版本dev是
    feature开发分支，实现新特性否
    test测试分支，功能测试fat是
    release预上线分支，发布新版本uat是
    hotfix紧急修复分支，修复线上bug否

    • 常见的各种分支

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

      • develop：开发分支，始终保持最新完成以及bug修复后的代码，用于前后端联调。一般开发的新功能时，feature分支都是基于develop分支创建的。

      • feature：开发新功能时，以develop为基础创建feature分支。

        分支命名时以 feature/ 开头，后面可以加上开发的功能模块， 命名示例：feature/user_module、feature/cart_module

      • test：测试分支，外部用户无法访问，专门给测试人员使用，版本相对稳定。

      • release：预上线分支（预发布分支），UAT测试阶段使用。一般由 test 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。

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

    • 常见的各种环境

      • pro（production environment）：生产环境，面向外部用户的环境，正式环境，连接上互联网即可访问。
      • sit（system Integration test）：系统集成测试，开发人员自己测试流程是否走通。
      • uat（user acceptance test environment）：用户验收测试环境，是用户接受测试，实际使用的场景。这个环境的主要目标是将产品或系统推送到用户使用。在UAT环境下，可能要考虑到更多的实际使用因素，比如产品的操作体验、使用效果、交互感受等。
      • test（test environment）：测试环境，外部用户无法访问，专门给测试人员使用的，版本相对稳定。
      • pre（pre-production environment）：灰度环境，外部用户可以访问，但是服务器配置相对低，其它和生产一样，外部用户可以访问，版本发布初期，正式版本发布前。
      • dev（development environment） ： 开发环境，外部用户无法访问，开发人员使用，版本变动很大。
      • fat（feature acceptance test environment）：功能验收测试环境，用于软件测试者测试使用。
      • sim（simulation environment）：仿真环境，模拟实际环境中的各种因素和条件，以验证系统的性能和可靠性。

    知识拓展

    • uat和sim的区别：UAT环境更注重实际使用效果，而SIM环境更注重系统内部的测试和验证

    分支合并流程规范

    业界常见的两大主分支（master、develop）、三个辅助分支（feature、release、hotfix）的生命周期：

    image-20231105233125253

    以上生命周期仅作参考，不同开发团队可能有不同的规范，可自行灵活定义。

    例如有的团队在开发时，会有以下的规定：

    1. develop 分支和 hotfix 分支，必须从 master 分支检出
    2. develop 分支需合并到 test 分支
    3. test 分支功能测试无误后，合并到 release 分支
    4. UAT 测试通过后，由 release 分支合并到 master分支
    5. 对于工作量小的功能开发（工时小于1天），可以直接在 devolop 分支进行开发；否则由 develop 分支检出 feature 分支进行开发，开发完后合并到develop 分支

    提交信息规范

    • 提交信息规范化的作用

      • 提高可读性：使用规范化的提交信息可以使代码历史更容易理解。明确的描述可以使其他人更容易地理解代码的变更和原因；

        如果团队遵循相同的提交信息格式，那么所有代码库的提交历史都将具有一致性，这有助于保持代码库的整洁和一致性。

      • 有利于问题追踪：清晰的提交信息可以帮助开发人员快速定位和解决问题，因为它们提供了有关代码变更的上下文和原因；

      • 降低团队沟通成本：在团队协作中，规范化的提交信息有助于团队成员之间的沟通和协作。每个人都可以轻松地查看和理解代码变更，而无需依赖个人记忆或理解。

    Angular提交规范

    目前最受开发人员肯定的规范是前端框架Angular提出的Angular提交信息规范，Angular 的 Git Commit 准则可以遵循一些基本的规则和最佳实践，以确保代码的整洁和可读性。

    • Angular提交格式：

      <type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

      • 1
      • 2
      • 3
      • 4
      • 5

      • type：提交类型，表示本次提交属于哪一种类型，常见的提交类型如下所示

        • build：对构建系统或者外部依赖项进行了修改
        • ci：对CI配置文件或脚本进行了修改
        • docs：对文档进行了修改
        • feat：增加新的特征
        • fix：修复 bug
        • pref：提高性能的代码更改
        • refactor：既不是修复 bug 也不是添加特征的代码重构
        • style：不影响代码含义的修改，比如空格、格式化、缺失的分号等
        • test：增加确实的测试或者矫正已存在的测试
        • delete：删除功能或文件
        • modify：修改功能
        • chore：对构建过程或辅助工具和库（如文档）的更改
        • revert：回滚到上一个版本

      • scope（可选项）：作用域，表示更改的范围，例如全局、部分功能、数据层、控制层、视图层等等，视项目不同而不同等

      • subject：主题，是一个简短的描述，用于概括此次提交的主要更改内容。通常应该包含关键词和主要变化点

        有以下准则：

        • 使用命令式，现在时态：“改变”不是“已改变”也不是“改变了”
        • 不要大写首字母
        • 不在末尾添加句号

      • body：主体，是详细的描述部分，也就是提交的正文描述信息，提供了对所提交更改的更详细的信息，包括更改的原因、具体步骤、结果等

        有以下准则：

        • 使用命令式、现在时态

        • 应该包含修改的动机以及和之前行为的对比

      • BLANK LINE：空行，用于进行分隔主体内容

      • footer（可选项）：页脚，通常包含有关此次提交的其他信息，如提交人、提交时间、相关issue或PR号等

        常用取值如下：

        • BREAKING CHANGE：表示本次提交是不兼容修改，不兼容修改指的是本次提交修改了不兼容之前版本的 API 或者环境变量
        • Closes：表示本次提交目的是修改 issue，一般后面跟上 issue 的编号，表示成功解决了这个编号的 issue
        • revert：表示本次提交中包含了回滚内容

    • Angular Git Commit 准则的建议：

      • 每个提交应该只包含一个相关的更改。
      • 使用有意义的 commit 描述，清晰地描述更改的内容和原因。
      • 使用英文编写 commit 描述，以提高可读性和理解度。
      • 使用主次信息格式，包括类型（feat、fix、docs、style、refactor、perf、test）、描述性标题和详细信息。
      • 使用短行，每行不超过 72 个字符。
      • 避免使用代词 “it”，使用名词或动词来描述代码更改。
      • 在 commit 描述中包含 issue 或 PR 号，以便于追踪和合并更改。
      • 在 commit 消息中标记特性分支（feature），以区分不同特性的开发工作。

    示例：

    feat(user): 添加用户登录功能

新增了用户登录功能，包括用户认证和权限控制。

BREAKING CHANGE: 修改了用户认证接口的返回格式

Closes #123

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7

    在这个示例中，提交类型为 feat（新功能），作用域为 user，描述了添加用户登录功能的修改。同时，还包含了详细的描述、BREAKING CHANGE （破坏性变更的说明）和 Closes #123都是 footer

    注意事项

    • 提交注意事项：

      • 提交问题必须为同一类别

      • 提交问题不要超过3个

        • 提交的commit发现不符合规范，①git commit --amend -m "新的提交信息"或② git reset --hard HEAD 重新提交一次

          ①讲暂存区中的提交合并到当前提交

          ②丢弃暂存区中的提交并切换到最新提交

          注意：②这个命令会永久性地删除暂存区的（也就是执行了add但是没有执行commit的内容）修改，所以在使用时要非常小心

    • 分支注意事项：

      • master 分支的每一次更新，都建议打 tag 添加标签，通常为对应版本号，便于管理
      • feature分支、hotfix分支在合并后可以删除，避免分支过多管理混乱

    • 拉取注意事项：

      • 每次编码前都先 pull 一下，有效防止远程库与本地库冲突导致无法提交，因为远程库代码可能发生了更新，但是我们本地库没有更新
      • 每次 pull 代码前，提交本地代码到本地库中，否则可能回出现合并代码出错，导致代码丢失

    通用Git忽略文件配置

    下面是一份通用的Git忽略文件配置，让我们提交的文件更加简洁、干净

    HELP.md
target/
!.mvn/wrapper/maven-wrapper.jar
!**/src/main/**/target/
!**/src/test/**/target/

### STS ###
.apt_generated
.classpath
.factorypath
.project
.settings
.springBeans
.sts4-cache

### IntelliJ IDEA ###
.idea
*.iws
*.iml
*.ipr

### NetBeans ###
/nbproject/private/
/nbbuild/
/dist/
/nbdist/
/.nb-gradle/
build/
!**/src/main/**/build/
!**/src/test/**/build/

### VS Code ###
.vscode/

# Log file
*.log
/logs*

# BlueJ files
*.ctxt

# Mobile Tools for Java (J2ME)
.mtj.tmp/

# Package Files #
*.jar
*.war
*.ear
*.zip
*.tar.gz
*.rar
*.cmd

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52

    参考资料

  • 相关阅读:
    使用 rollup 打包一个原生 js + canvas 实现的移动端手势解锁功能组件
    面向对象设计模式之访问者模式
    C++【多态】
    JavaScript对象详解，js对象属性的添加
    怎么给图片名称快速重命名？来跟我学着两个实用方法
    【从零开始学习 UVM】1.3、UVM 概述 —— UVM Introduction
    KubeCon热点报告：AIStation调度平台实现RoCE网络下大模型的高效稳定训练
    信息化带来的制造业生产管理系统究竟有哪些作用呢？
    树的常见面试题
    品甜蜜“醇时代”，享幸福“鑫品质”豫鑫糖醇盛装亮相2023生物发酵展
  • 原文地址：https://blog.csdn.net/qq_66345100/article/details/134237354