Git 开发规范

Git 是一种分布式版本控制系统，广泛应用于软件开发中。为确保团队协作高效、代码管理清晰，遵循一定的 Git 开发规范非常重要。以下是常见的 Git 开发规范。

1. 提交信息规范

提交信息格式：每次提交的信息应简洁、清晰，遵循以下格式：
```
<类型>(<范围>): <简短描述>

<详细描述>
```
例如：
```
feat(user): add login functionality

- Implement user login API
- Update user model with password hash field
```
常用的类型包括：
- feat：新特性
- fix：修复 bug
- docs：文档变更
- style：代码格式（不影响功能的变动）
- refactor：代码重构
- perf：性能优化
- test：增加测试
- chore：其他不改变功能的变更
提交信息长度：提交标题应简洁，限制在 50 个字符以内；详细描述应不超过 72 个字符。
详细描述：如果有必要，可以在提交信息的详细描述中提供更详细的说明，描述为什么做这些修改，修改的背景及影响。

主分支：保持 main 或 master 为主分支，不进行直接开发。所有开发工作都应在其他分支上进行。
开发分支：创建用于开发的分支时，使用如下命名规则：
- feature/：新功能开发分支
- bugfix/：修复 bug 的分支
- hotfix/：紧急修复分支
- release/：发布版本分支
- test/：测试分支
- chore/：小的杂项任务分支
例如：
```
feature/user-authentication
bugfix/login-error
hotfix/fix-undefined-error
```
命名规范：分支名称应简洁且有意义，能够清晰表达该分支的功能或目标，避免使用过长的名称。

小而频繁的提交：将大范围的功能或修复拆分成多个小的提交，以便代码审查和调试。
避免在 main 或 master 直接提交：开发时，应避免直接在 main 或 master 分支上进行提交。所有功能开发、修复应在独立的分支上进行，提交前进行本地测试。
在合并时使用“Squash Merge”：将多个提交合并成一个提交，这样能够保持 Git 历史记录的整洁。

标签（Tag）使用：版本发布时，应该在 Git 中使用标签进行标记，标签命名规范如下：
- 使用 v 前缀加上版本号（如 v1.0.0）。
- 遵循语义化版本控制（Semantic Versioning）规范：MAJOR.MINOR.PATCH。
例如：
```
git tag v1.0.0
git push origin v1.0.0
```