前端开发

Appearance

git 规范 ​

为什么要规范 ​

在团队协作开发中，如果没有统一的 Git 使用规范，会带来以下问题：

  • 提交信息混乱，无法快速了解每次变更的内容
  • 分支管理混乱，容易出现代码冲突和丢失
  • 代码审查困难，无法有效追踪问题来源
  • 版本发布混乱，难以回溯和定位问题

因此，制定统一的 Git 规范，是团队协作的基础保障。

分支管理规范 ​

采用 Git Flow 分支模型进行项目管理：

分支名称说明命名规范
main / master主分支，存放稳定的生产环境代码-
develop开发分支，日常开发的集成分支-
feature/*功能分支，从 develop 切出，开发完成后合并回 developfeature/功能名称，如 feature/user-login
hotfix/*热修复分支，从 main 切出，修复完成后合并回 main 和 develophotfix/问题描述，如 hotfix/fix-login-bug
release/*预发布分支，从 develop 切出，用于发布前的测试release/版本号，如 release/1.2.0

注意

  • 禁止直接在 main 和 develop 分支上进行开发
  • 功能分支开发完成后，应通过 Merge Request（MR） 合并，而非直接 push
  • 合并前必须进行代码审查（Code Review）

Commit 提交规范 ​

采用 Conventional Commits 规范，提交信息格式如下：

<type>(<scope>): <subject>

<body>

<footer>

type 类型说明 ​

类型说明
feat新增功能
fix修复 Bug
docs文档变更
style代码格式调整（不影响代码运行）
refactor重构（既不是新增功能，也不是修复 Bug）
perf性能优化
test新增或修改测试用例
chore构建过程或辅助工具的变动
ciCI 配置文件或脚本变更
revert回退某个 commit

示例 ​

bash
# 新增功能
git commit -m "feat(user): 新增用户登录功能"

# 修复bug
git commit -m "fix(auth): 修复token过期后未跳转登录页的问题"

# 文档更新
git commit -m "docs(readme): 更新项目启动说明"

# 代码重构
git commit -m "refactor(utils): 重构请求封装类"

提交规范

  • subject 使用中文描述，简短清晰，不超过 50 个字符
  • body 可选，用于详细描述变更原因和具体内容
  • 每次提交应该是一个原子性的改动，避免将多个不相关的修改放在同一个 commit

如何规范 ​

采用 husky + commitlint + lint-staged 对代码提交进行自动化规范处理。

1. 安装依赖 ​

bash
# 安装 husky
npm install husky -D

# 安装 commitlint
npm install @commitlint/cli @commitlint/config-conventional -D

# 安装 lint-staged
npm install lint-staged -D

2. 初始化 husky ​

bash
# 初始化 husky
npx husky install

# 在 package.json 中添加 prepare 脚本
npm pkg set scripts.prepare="husky install"

3. 添加 commit-msg 钩子 ​

bash
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

4. 配置 commitlint ​

在项目根目录创建 commitlint.config.js：

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

5. 配置 lint-staged ​

在 package.json 中添加：

json
{
  "lint-staged": {
    "*.{js,jsx,ts,tsx,vue}": ["eslint --fix", "prettier --write"],
    "*.{css,scss,less}": ["prettier --write"]
  }
}

6. 添加 pre-commit 钩子 ​

bash
npx husky add .husky/pre-commit 'npx lint-staged'

合并与代码审查 ​

  1. 合并方式：推荐使用 Squash and Merge，保持主分支提交历史整洁
  2. 代码审查：
    • 每个 MR 至少需要一位其他成员审查通过
    • 审查重点关注：代码质量、业务逻辑、安全性、性能
    • 审查通过后方可合并
  3. 冲突处理：
    • 合并前先将目标分支最新代码合并到当前分支
    • 手动解决冲突后，确保功能正常再提交

.gitignore 规范 ​

项目必须配置 .gitignore 文件，避免提交不必要的文件：

txt
# 依赖目录
node_modules/

# 构建产物
dist/
build/

# 编辑器配置
.idea/
*.swp
*.swo

# 系统文件
.DS_Store
Thumbs.db

# 环境配置（含敏感信息）
.env.local
.env.*.local

# 日志文件
*.log
npm-debug.log*