Git 开发规范 - 技术栈

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

Git 开发规范指南

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

一、分支管理规范

1. 主分支（长期存在）

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

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

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

二、Commit 消息规范

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

git 复制代码

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]

四、代码合并规则

团队必须：
- 通过 Pull Request (GitHub) / Merge Request (GitLab) 合并
- ≥1 人 Code Review 通过
- 通过 CI/CD 流水线检查
单人建议：
- 在合并前执行回归测试
- 使用 git merge --no-ff 保留分支历史

五、代码同步规范

bash 复制代码

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

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

六、冲突解决原则

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

七、最佳实践补充

.gitignore 必须配置（排除日志、临时文件等）

提交前检查：

bash 复制代码

git diff --cached  # 检查暂存区
git status         # 检查文件状态

团队项目推荐工具：
- 分支保护规则（禁止直接 push main）
- PR 模板（标准化描述）
- CI/CD 自动化（自动测试/lint）

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

重点差异说明

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

使用提示：

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