Git 规范
在实际开发中，遵循一定的 Git 规范可以提高团队合作效率，减少冲突和混乱。以下是一些常见的 Git 规范：
1. 提交信息规范
1.1 提交信息格式
- 每条提交信息应包含一个简洁的标题和可选的正文。
- 标题应简洁明了，长度不超过 50 个字符，并且使用动词的原形。
- 正文部分应解释为什么要做这个变更，描述变更的目的和背景，建议长度不超过 72 个字符每行。
示例：
修复用户登录时的错误
在用户登录过程中，修复了一个导致应用崩溃的错误，增加了错误处理逻辑。
1.2 提交类型
可以使用类似于以下的类型前缀来标识提交的类型：
feat:新功能fix:修复错误docs:文档更新style:代码格式（不影响功能的变更）refactor:代码重构test:添加缺失的测试chore:维护性工作
示例：
feat: 增加用户注册功能
2. 分支管理规范
2.1 分支命名
- 使用小写字母，单词之间使用短横线分隔。
- 分支名称应简洁且具描述性，能反映分支的目的。
示例：
feature/user-registration
bugfix/login-error
2.2 分支策略
main或master分支：用于生产环境的稳定版本，禁止直接在该分支上进行开发。develop分支：用于集成开发中的所有功能，开发者应从该分支创建新功能分支。- 功能分支：每个新功能或修复应在独立的分支上开发，开发完成后提交合并请求到
develop分支。
3. 合并请求规范
3.1 合并请求描述
- 合并请求应包含详细描述，说明实现的功能和变更的原因。
- 应附上相关的 issue 链接，以便于追踪。
3.2 代码审查
- 在合并请求中，建议至少有一位开发者进行代码审查，确保代码质量和功能正确性。
- 使用评论或建议功能，提出改进意见。
4. 标签管理规范
4.1 标签命名
- 标签应遵循语义化版本控制（SemVer）原则。
- 格式应为
vX.Y.Z，其中 X 代表主版本，Y 代表次版本，Z 代表修订版本。
示例：
v1.0.0
v1.1.0
v1.1.1
4.2 标签发布
- 发布新版本时，应在
main或master分支上打标签。 - 同时更新变更日志，记录版本更新内容。
5. 其他注意事项
5.1 保持提交历史整洁
- 在开发完成后，使用
rebase或squash合并提交，保留有意义的提交信息，删除不必要的提交。
5.2 定期清理分支
- 定期检查和清理已合并或不再使用的分支，避免分支数量过多导致混乱。
5.3 处理冲突
- 在合并过程中如遇冲突，应及时解决，并确保代码的正确性和完整性。
遵循以上 Git 规范，可以帮助团队在开发过程中保持高效和有序，提高代码质量和项目的可维护性。
