Git 开发规范

div代码工厂
241 阅读3分钟

以下是一份适用于 单人开发 和 团队协作 的 Git 开发规范文档

Git 开发规范指南

本规范适用于 单人项目 和 团队协作项目，旨在提高代码管理效率和可维护性。

一、分支管理规范

1. 主分支（长期存在）

分支名环境描述
main生产环境稳定版本，禁止直接 push
dev测试环境集成开发分支，功能测试用

2. 辅助分支（临时分支，用完删除）

分支类型命名规则用途
功能分支feat/xxx新功能开发 (例: feat/user-login)
修复分支fix/xxxBug 修复 (例: fix/profile-avatar)
重构分支refactor/xxx代码重构
文档分支docs/xxx文档更新
单人开发建议topic-xxx单人项目可简化命名 (例: topic-search-optimize)

二、Commit 消息规范

格式：<type>(<scope>): <subject>

feat(user): add password reset function
^    ^       ^
|    |       |- 简短描述（英文小写开头，无句号）
|    |- 模块/范围（可选）
|- 提交类型（必选）

常用类型：

类型说明
feat新增功能
fix修复 bug
docs文档更新
style代码格式调整（非功能）
refactor代码重构
test测试相关
chore构建/工具依赖调整

单人特别提示：保持规范提交，便于未来回溯代码变更历史。

三、工作流程

团队协作流程：

graph LR
    A[从dev拉取feat分支] --> B[本地开发]
    B --> C[推送feat分支]
    C --> D[创建PR/MR]
    D --> E[代码审查]
    E --> F[合并到dev]
    F --> G[测试通过]
    G --> H[合并到main]

单人简化流程：

graph LR
    A[从main拉取topic分支] --> B[本地开发]
    B --> C[本地测试]
    C --> D[合并到main]

四、代码合并规则

  1. 团队必须：

    • 通过 Pull Request (GitHub) / Merge Request (GitLab) 合并
    • ≥1 人 Code Review 通过
    • 通过 CI/CD 流水线检查

  2. 单人建议：

    • 在合并前执行回归测试
    • 使用 git merge --no-ff 保留分支历史

五、代码同步规范

# 团队协作时每日开始前操作：
git checkout dev
git pull origin dev   # 更新dev分支
git checkout feat/xxx
git merge dev         # 合并最新代码到当前分支

# 单人项目定期同步：
git checkout main
git pull --rebase

六、冲突解决原则

  1. 团队协作：
    • 冲突创建者负责解决
    • 在 PR 内解决，禁止直接 push 冲突代码
  2. 单人项目：
    • 使用 VS Code 或 git mergetool 可视化解决
    • 解决后立即提交：
    git add .
git commit -m "fix: resolve merge conflicts"

七、最佳实践补充

  1. .gitignore 必须配置（排除日志、临时文件等）
  2. 提交前检查： 
    git diff --cached  # 检查暂存区
git status         # 检查文件状态
  3. 团队项目推荐工具：
    • 分支保护规则（禁止直接 push main）
    • PR 模板（标准化描述）
    • CI/CD 自动化（自动测试/lint）

规范不是枷锁，而是高效协作的基石。根据项目规模灵活调整细节，保持一致性最重要。

重点差异说明

场景核心差异点推荐实践
单人开发分支策略简化使用topic-xxx代替feat/xxx
无需强制 PR本地测试后直接合并
团队协作严格的分支保护必须通过 PR/MR 合并
强调 Code Review使用 PR 模板和审查清单
依赖自动化工具配置 CI/CD 和质量门禁

使用提示：

  1. 团队项目：将此文档放入仓库 .github/ 或 docs/ 目录
  2. 单人项目：关注 提交规范 + 分支管理 即可
  3. 使用 Git 钩子自动化验证（如 Commitlint）
avatar
文章
阅读
粉丝