Git

git commit paradigm

Git 提交范式通常指的是在进行 Git 提交时所遵循的一种规范化格式，以便于团队协作和代码管理。常见的提交信息格式包括以下几个部分：

1. 类型 (type): 提交的类型，常见的有：

   • feat: 新功能
   • fix: 修复 bug
   • docs: 文档变更
   • style: 代码格式（不影响代码运行的变更）
   • refactor: 代码重构（既不是修复 bug 也不是添加功能）
   • test: 添加测试
   • chore: 其他杂项变更

2. 范围 (scope): 可选，表示影响的模块或功能范围，例如 api、ui 等。

3. 描述 (description): 简要描述提交的内容，通常不超过 72 个字符。

4. 正文 (body): 可选，详细描述提交的内容和原因，换行后写。

5. 脚注 (footer): 可选，通常用于关联问题或任务，例如 Closes #123。

示例

feat(api): add user login endpoint

This commit adds a new endpoint for user login, allowing users to authenticate using their email and password.

Closes #42

提交规范工具

为了帮助团队遵循提交规范，可以使用一些工具，如:

• Commitlint: 用于检查提交信息是否符合规范。
• Husky: 用于在 Git 钩子中运行 lint 检查。

Git 分支用途及规范

在 Git 项目中，分支管理是确保代码质量、团队协作效率和开发流程稳定的重要环节。以下是常见分支的用途及其适用场景：

• main 分支 主分支，通常用于生产环境的代码部署。它是最终稳定版本的存储地，任何代码变更都需要经过严格测试后才能合并到此分支。
• dev 分支 开发分支，团队日常开发的主要分支。新功能的开发通常基于此分支创建子分支，确保主分支的稳定性。
• release 分支 发布分支，用于新版本的发布准备。开发完成后，代码从 dev 分支合并到 release 分支进行测试，修复完成后再合并到 main 和 dev。
• hotfix 分支 热修复分支，用于紧急修复生产环境中的问题。以 main 分支为基线创建，修复完成后需合并回 main 和 dev。
• future 分支 待开发分支，适用于代码变动较大的新功能开发。通常用于长期规划的功能，避免对现有开发流程的干扰。
• feature 分支 功能分支，用于开发较小的新功能。以 dev 分支为基线创建，开发完成后合并回 dev。
• staging 分支 测试分支，用于测试新功能的稳定性。通常在功能开发完成后，从 release 或 dev 分支创建。

通过合理使用这些分支，可以实现代码的模块化管理，支持敏捷开发模式，并确保生产环境的稳定性和可靠性。