Git 代码规范

Git
学习记录
发布日期:   2024-05-16
文章字数:   750
阅读时长:   2 分
阅读次数:  

Git 代码规范指南

本指南介绍了 Git Commit 的标准写法以及常见分支的命名规则，帮助团队统一代码管理流程。

📝 Git Commit Message 规范

一个规范的提交信息包括：

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

<body>

<footer>

1. type（类型）

用于说明本次提交的目的：

类型 描述
feat ✨ 新功能
fix / to 🐞 修复 Bug（fix：自动修复；to：逐步修复）
docs 📝 修改文档
style 💄 代码格式（无功能变更）
refactor ♻️ 代码重构（非功能修改）
perf ⚡ 性能优化
test ✅ 添加或修改测试
chore 🔧 构建或辅助工具变动
revert ⏪ 回滚上一个版本
merge 🔀 合并代码
sync 🔄 同步主线或分支的 Bug
improvement 🔨 功能改进
ci 🛠️ 持续集成相关改动
build 📦 打包相关变动

2. scope（可选范围）

用于说明影响范围，写在括号中。例如：

  • feat(login)：登录模块的功能新增
  • fix(api)：API 模块的 Bug 修复

3. subject（简短说明）

一句话描述本次提交的目的，不超过 50 个字符，结尾不加标点。

✅ 示例：

fix(DAO): 用户查询缺少 username 属性  
feat(Controller): 开发用户查询接口

4. body（详细描述）

用于说明此次提交的背景、目的与改动点。
建议每行不超过 72 个字符。

5. footer（脚注说明）

用于关联 Issue、记录重大变更：

  • 关联 Issue：
    Closes #123 或 Fixes #123

  • 破坏性变更：
    BREAKING CHANGE: <说明>

🌿 分支命名规范

为了保证代码协作有序，约定如下分支命名方式：

1. main / master：主分支

  • 用途：发布稳定版本代码
  • 规则：禁止直接提交，只能通过合并其他分支更新

2. develop：开发分支

  • 用途：集成功能分支开发成果
  • 规则：从 main 创建，所有功能合并回 develop

3. feature/ 或 feat/：功能分支

  • 命名：feature/<功能名> 或 feat/<功能名>
  • 规则：从 develop 创建，合并回 develop
  • ✅ 示例：
    feature/user-authentication
    feat/add-payment-gateway

4. bugfix/ 或 fix/：Bug 修复分支

  • 规则：从 develop 创建，修复后合并回 develop
  • ✅ 示例：
    bugfix/login-error
    fix/null-pointer-exception

5. release/：发布分支

  • 规则：从 develop 创建，发布后合并回 main 与 develop
  • ✅ 示例：
    release/v1.0.0
    release/2023-10-01

6. hotfix/：紧急修复分支

  • 规则：从 main 创建，修复后合并回 main 和 develop
  • ✅ 示例：
    hotfix/critical-security-issue
    hotfix/login-page-crash

7. support/：旧版本维护分支

  • 规则：从 main 创建，用于维护旧版本
  • ✅ 示例：
    support/v1.0.x

🚀 分支命名最佳实践

建议 示例
使用小写 + 连字符 feature/user-authentication
避免空格或特殊符号 ❌ feature/User Authentication
包含上下文和任务号 feature/PROJ-123-add-search
保持简洁 ✅ fix/api-timeout；❌ fix/api-request-timeout-due-to-long-queue

📌 推荐工作流参考图

通过规范化 Git 提交流程和分支管理，团队协作会更加高效统一，利于代码审查和版本追踪。如有需要，也可以将此规范集成到 CI 流程中。

Git
  目录