【提交人】：
【版本号】：
【提交类型】：
【问题描述】：
【修改内容】：
【修改文件】：

build：涉及构建相关的改动（如升级 npm 包、修改 webpack 配置等）
chore：构建过程或辅助工具的变更
ci：持续集成相关的改动
docs：文档相关的变更
feat：新增特性或功能
fix：bug 修复
perf：性能相关改动
refactor：重构相关（非 bug、非新功能）
revert：回滚 commit
style：代码风格的调整，如格式化、空格等
test：测试相关，包括新增测试或者更改已有测试

1、提交频率

尽量保持提交频率较小，每个提交应该只包含一个逻辑上的更改或修复。

2、提交信息格式

每个提交应该包含一个简明扼要的提交信息。

3、分支管理

使用合理的分支管理策略，例如：
1、主分支（通常是 master 或 main）用于部署稳定的版本。
2、开发分支（例如 dev）用于进行功能开发和集成测试。
3、修复分支（例如 bugfix/xxx）用于解决问题和修复 bug。
4、在进行功能开发时，可以从开发分支创建特性分支（例如 feature/xxx），完成后再合并到开发分支。

自动化校验

通过使用 Git hooks 达成目的。

想使用相关的 Git Hooks，可以在目录 .git/hooks 创建对应的文件，文件名为 prepare-commit-msg 及 commit-msg，并赋予可执行权限。这样在我们进行 git commit 操作时，对应的脚本就会执行。

Git 的提交不会包含 .git 目录，所以对应的 hooks 的改动并不会被提交到仓库中。我们可以在仓库根目录 创建 .githooks 文件夹并将我们实现的代码放到该目录中

Husky的官网：Husky - Git hooks (typicode.github.io)

husky 工具配置代码检查工作流的作用

在工作中，我们经常需要将写好的代码提交至代码仓库
但是由于程序员疏忽而将不规范的代码提交至仓库，显然是不合理的
所以我们需要引入一种检查机制，若代码不规范，就不允许提交

提交前做代码检查

husky 是一个 git hooks 工具 ( git的钩子工具，可以在特定时机执行特定的命令 )

husky 配置

1、git 初始化 git init（若已有仓库则跳过这一步）
2、初始化 husky 工具配置 Husky
3、修改 .husky / pre-commit 文件

• 删除掉或者注释掉默认配置 npm test

• 添加 npm run lint

  
  
  image.png

暂存区 eslint 校验

问题：npm run lint 默认进行的是全量检查，耗时问题，历史问题

耗时问题：如果项目过大，校验耗时也大
历史问题：且如果拉取同事的代码，校验之后发现同事的代码有很多规范问题，我们还要替同事背这个锅，显然不合理。因为 eslint 的校验可能并不是一开始就有的，而是在工作过程中逐步建立起来的，所以可能旧的代码没有经过校验就被提交了

所以能不能改改机制，每次提交都只检查最新改动的代码？这样才符合实际工作需求，所以 lint-staged 诞生了

lint-staged

安装

npm install lint-staged -D

配置 package.json

{
    "scripts": {
        "lint-staged": "lint-staged"
    }
    "lint-staged": {
        "*.{js,ts,vue}": [
            "eslint --fix"
        ]
    }
}

修改 .husky/pre-commit 文件

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npm run lint-staged

.sh 文件中第一行 #!/bin/bash -il 是什么

是执行该脚本文件的解释器的路径和选项！

在一个 shell 脚本文件的第一行加上 #！符号，称为 shebang，它告诉系统使用哪个解释器执行这个脚本。在 #!/bin/bash 的例子中，它告诉系统使用 Bash 解释器执行这个脚本。

-i 选项表示 Bash 进入交互式模式，-l 选项表示 Bash 作为登录 shell 运行，它会在 Bash 启动时执行 /etc/profile 和 ~/.bash_profile 文件，以便设置环境变量和别名等。

所以 #!/bin/bash -il 的作用是告诉系统使用 Bash 解释器以交互式登录方式执行这个脚本，并在执行前加载 /etc/profile 和 ~/.bash_profile 文件，以便设置正确的环境变量和别名等。

交互式登录方式是什么

在 Bash 中，有两种运行方式：登录 shell 和 非登录 shell。

登录 shell 是指当你第一次登录系统时，系统会为你分配一个 shell 进程，这个 shell 进程就是登录 shell，它会读取 /etc/profile 和 ~/.bash_profile 文件，以便设置环境变量和别名等。

非登录 shell 是指在已经登录的 shell 环境中再次打开一个 shell 环境，这个 shell 进程就是非登录 shell，它不会读取 /etc/profile 和 ~/.bash_profile 文件，而是读取 ~/.bashrc 文件。

交互式是指在 shell 环境中可以接收用户输入，并根据用户输入执行命令。非交互式则是指在 shell 环境中执行一条或多条命令，不需要用户输入。

所以 -i 选项表示以交互式方式运行 Bash，可以让用户和脚本进行交互。而 -l 选项表示以登录 shell 方式运行 Bash，可以让脚本获取正确的环境变量和别名等。

~/.bash_profile中的~是什么

在 Linux 和 类 Unix 系统中，~ 表示当前用户的 home 目录，例如 /home/username 或 /Users/username。~/.bash_profile 就是当前用户的 Bash 配置文件，它通常包含了一些用户自定义的环境变量、别名、函数等。

在 Linux 中，~ 实际上是一个 shell 内置的变量，它表示当前用户的 home 目录，可以通过 echo $HOME 命令来查看。

在 Bash 中，~ 还可以用来表示其他用户的 home 目录，例如 ~username 就表示 username 用户的 home 目录。

.sh 文件中第一行可以不写 #!/bin/bash -il 吗？如果可以不写，默认是什么?

可以。第一行通常是指定解释器的路径和选项。如果你不指定解释器，系统会使用默认的解释器来执行脚本。在 Linux 系统中，通常默认的解释器是 /bin/sh。

因此，如果你不写 #!/bin/bash -il 这样的解释器路径和选项，那么默认情况下脚本会使用 /bin/sh 解释器来执行。这种情况下，脚本文件中的 Bash 特定的语法和命令可能无法被正确解释执行，因为 /bin/sh 解释器不支持 Bash 特有的语法和命令。

因此，如果你想使用 Bash 解释器来执行脚本，最好在脚本文件的第一行指定解释器路径和选项，例如：

#!/bin/bash

这样可以确保脚本会在 Bash 环境下运行，从而避免可能的语法和命令兼容性问题。

常用的几种 shell

Shell 既是一种脚本编程语言，也是一个连接内核和用户的软件。
常见的 Shell 有 sh、bash、csh、tcsh、ash，zsh 等。

sh
sh 的全称是 Bourne shell，由 AT&T 公司的 Steve Bourne开发，为了纪念他，就用他的名字命名了。
sh 是 UNIX 上的标准 shell，很多 UNIX 版本都配有 sh。sh 是第一个流行的 Shell。

bash
bash shell 是 Linux 的默认 shell，bash 由 GNU 组织开发，保持了对 sh shell 的兼容性，是各种 Linux 发行版默认配置的 shell。
bash 兼容 sh 意味着，针对 sh 编写的 Shell 代码可以不加修改地在 bash 中运行。
尽管如此，bash 和 sh 还是有一些不同之处：
一方面，bash 扩展了一些命令和参数；
另一方面，bash 并不完全和 sh 兼容，它们有些行为并不一致，但在大多数企业运维的情况下区别不大，特殊场景可以使用 bash 代替 sh。

csh
sh 之后另一个广为流传的 shell 是由柏克莱大学的 Bill Joy 设计的，这个 shell 的语法有点类似 C 语言，所以才得名为 C shell ，简称为 csh。

tcsh
tcsh 是 csh 的增强版，加入了命令补全功能，提供了更加强大的语法支持。

ash
一个简单的轻量级的 Shell，占用资源少，适合运行于低内存环境

Linux 系统中查询安装了哪些命令行解释器

cat /etc/shells

Linux 系统中查询当前使用的命令行解释器

echo $SHELL