Git 分支规范

0.简介

Git 分支规范是一套约定，用以指导团队成员如何命名和管理 Git 仓库中的分支。

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

1.分支命名

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

• 主分支（Main）

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

• 开发分支（Develop）

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

# 从 main 创建 develop 分支gitswitch-cdevelop main# 从 develop 检出特性分支gitswitch-cfeature/add-user-authentication develop# 特性开发完成后合并回 developgitswitch developgitmerge --no-ff feature/add-user-authentication# --no-ff 禁用快进合并，强制创建合并提交，保留特性分支的历史轨迹，便于后续追溯

• 特性分支（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 并打标签（tag），最后也应合并回 develop。

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

• 测试分支（Test）

为测试相关代码（单元测试、集成测试、测试工具开发等）创建分支时使用test/前缀，如test/v2508_add_unit_tests。

• 其他类型的分支

前缀chore/适用于与业务功能无关的维护性任务（如工具链配置、告警规则优化、代码风格调整）。

chore/v2508_warning_optimize chore/v2508_cleanup_deprecation_notices

前缀refactor/适用于非业务功能变更的代码结构重构，其核心特点是不改变外部功能行为，仅优化代码内部结构。

refactor/v2508_split_big_funcs refactor/v2508_unify_naming_style

2.分支使用

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

3.代码发布

• 预发布环境验证可以使用非主分支发布，如特性分支（Feature）和修复分支（Bugfix）。
• 灰度和正式环境发布只允许使用主分支进行发布。
• 主分支设置了提交保护，代码合并到主分支需要审核通过。

参考文献

语义化版本2.0.0