Git 分支规范

Git 分支规范是一套约定，用以指导团队成员如何命名和管理Git仓库中的分支。这些规范有助于团队成员快速理解各个分支的作用，以及它们在项目中如何被使用。

实施一致的分支规范可以提高团队协作效率，简化版本控制流程，并帮助自动化持续集成/持续部署（CI/CD）流程。

1.分支命名

以下是一些广泛采用的Git分支命名和管理规范：

• 主分支（Main）

main 是主分支，包含生产环境的代码，应始终保持稳定和可部署状态。

• 开发分支（Develop）

develop 是次级主分支，用作开发的主要基线，所有特性分支都从此分支检出，并最终合并回来。

• 特性分支（Feature）

feature/ 前缀用于新功能开发的分支。例如：feature/add-user-authentication，feature/improve-ui-layout。

特性分支从 develop 分支检出，并在完成后合并回 develop。如果没有 develop 分支，则直接从 main 检出，并在完成后合并回 main。

• 修复分支（Bugfix）

bugfix/ 前缀用于错误修复的分支。例如：bugfix/login-fail，bugfix/memory-leak。

修复分支通常从 develop 分支检出，并在修复后合并回 develop。如果没有 develop 分支，则直接从 main 检出，并在完成后合并回 main。

• 热修复分支（Hotfix）

hotfix/ 前缀用于生产环境中紧急问题的修复。例如：hotfix/critical-security-patch。

热修复分支从 main 分支检出，并在修复后合并回 main。

• 发布分支（Release）:

release/ 前缀用于即将发布的版本。例如：release/v1.0.1。

发布分支从 develop 分支检出，用于最终的测试和微调，然后合并到 main 并打标签（tagging），最后也应合并回 develop。

标签用于标记发布点，如版本发布。标签应该遵循语义化版本命名，例如：v1.2.0。

2.分支使用

• 主分支代码需要保证随时可以发布。
• 原则上一个需求或者一个bug单独一个分支，不允许共用分支。
• 针对测试环境不够用的场景，需要多个需求或者bug在同一台机器上复用的场景，需要新建一个测试分支，相关的需求和bug分支合并到测试分支，代码变更需要在原来的分支上修改，修改后在合并到测试分支，不允许直接在测试分支上修改代码。

3.代码发布

• 灰度和正式环境发布只允许使用主分支进行发布，主分支设置了提交保护，代码合并到主分支需要审核通过。

参考文献

语义化版本2.0.0