Git 分支命名约定

在一家大型公司工作，项目规模可能从一人团队突然扩大到20人，因此拥有一个易于管理的代码仓库至关重要。大多数概念验证项目都是从一个仓库开始的，所有更改都直接应用到主分支。当新开发人员的小项目突然受到关注时，通常会将一个仓库升级为一个合适的大型仓库。

就我而言，由于必须处理数十个类似的不同项目，所以我想出了这个分支命名约定。

我将这些分支分为两类：

代码流分支

我们希望这些分支能够永久地在存储库中可用，并遵循从开发到生产的代码更改流程。

• 开发（dev）

  所有新功能和错误修复都应提交至开发分支。开发者代码冲突的解决应尽早完成。

• 质量保证/测试（测试）

  包含所有可供 QA 测试的代码。

• 暂存（staging，可选）

  它包含利益相关者希望在正式投入生产之前以演示或提案形式提供的已测试功能。在此阶段，将决定是否将某个功能最终纳入生产代码。

• 硕士（硕士）

  生产分支，如果存储库已发布，则这是正在呈现的默认分支。

除了 Hotfixes 之外，我们希望我们的代码遵循从开发 > 测试 > 登台 > 生产的单向合并。

临时分支

顾名思义，这些是可以根据开发人员或部署人员的需要创建和删除的一次性分支。

• 特征

  任何针对新模块或用例的代码更改都应在功能分支上进行。此分支基于当前开发分支创建。所有更改完成后，需要提交拉取请求/合并请求，将所有这些更改提交到开发分支。

  例子：

  • 功能/集成-swagger
  • 功能/JIRA-1234
  • 功能/JIRA-1234_support-dark-theme

建议使用全部小写字母和连字符 (-) 分隔单词，除非是特定的物品名称或 ID。下划线 (_) 可用于分隔 ID 和描述。

• 错误修复

  如果在发布、冲刺或演示之后，功能分支所做的代码更改被拒绝，则此后任何必要的修复都应在 bugfix 分支上完成。

  例子：

  • 错误修复/更多灰色阴影
  • 错误修复/JIRA-1444_gray-on-blur-fix

• 热修复

  如果需要修复阻塞代码、打临时补丁、应用关键框架或配置变更等需要立即处理的情况，则应创建热修复。热修复不遵循代码集成的计划，可以直接合并到生产分支，之后再合并到开发分支。

  例子：

  • 修补程序/禁用端点零日漏洞
  • 修补程序/增加缩放阈值

• 实验

  任何不属于发布或冲刺阶段的新功能或新想法。用于测试的分支。

  例子：

  • 实验/暗黑主题支持

• 建造

  专门用于创建特定构建工件或执行代码覆盖运行的分支。

  例子：

  • 构建/jacoco-metric

• 发布

  用于标记特定发布版本的分支

  例子：

  • 发布/myapp-1.01.123

  Git 还支持标记存储库的特定提交历史记录。如果需要将代码签出或使用，则使用发布分支。

• 合并

  用于解决合并冲突的临时分支，通常用于最新开发分支与功能分支或修补程序分支之间的冲突。当多个开发人员正在开发的功能的两个分支需要合并、验证和最终确定时，也可以使用此分支。

  例子：

  • 合并/dev_lombok-重构
  • 合并/组合设备支持

任何组织都可以制定自己的惯例。这适用于我当前团队的需求，并且可能存在更好的方法可以改进这些惯例。您自己组织的惯例是什么？