使用 Git 和 GitHub

此页面描述了我们在 RabbitMQ 项目中使用 Git 的方式。

概述​

Git 是一个快速、强大的分布式源代码控制管理系统。它有大量的教程。

RabbitMQ 团队使用 Git 来管理我们几乎所有的源代码。

RabbitMQ 源代码仓库托管在 GitHub 上。本网站上的各个项目页面通常会指导您找到您需要检出的模块的具体组合。

本网站也是开源的，并托管在 GitHub 上。

分支策略：每个问题一个分支​

RabbitMQ 在开发 RabbitMQ 代码时使用“每个问题一个分支”的技术，其中每个功能或错误修复都在其自己的分支上开发，使用

并在通过 QA 后才合并到 main 或 stable 分支。分支遵循 repository-name-NN 模式，其中 repository-name 是提交问题的 GitHub 项目的名称（例如 rabbitmq-dotnet-client），NN 是 GitHub 问题编号。在问题前加上仓库名称的目的是因为一个问题可能需要更改多个项目。还有一些分支名为 bugNNNNN，用于原始 Bugzilla 跟踪器（不公开）中的问题。

拉取请求和审查/QA 流程​

准备好审查和/或 QA 的分支应作为拉取请求提交。然后在评论中给出反馈。收到反馈后，更新原始分支并推送：GitHub 将负责更新拉取请求。然后该过程继续进行，直到拉取请求被合并或关闭（例如，因为在尝试实现某个功能后该功能被拒绝）。

如果拉取请求是错误修复，且不涉及与最新稳定版本的不兼容更改（即，不对 Mnesia 模式或节点间通信进行更改），则必须针对 stable 分支创建拉取请求；对于其他所有情况，则针对 main 分支创建拉取请求。

主分支​

默认仓库分支包含所有已经过 QA 的工作，这些工作计划在下一个功能版本中发布。

通常，您可以通过跟踪您感兴趣的 RabbitMQ 仓库的主（默认）分支来跟踪经过 QA 的开发工作。

计划在当前维护的发布系列（例如 3.11.x）中发布的拉取请求会被反向移植到特定于发布系列的分支。

发布系列分支​

对于当前维护的每个发布系列，都有一个单独的分支。这些分支以系列命名：v3.13.x、v3.12.x 等等。

它的作用与主分支相同，只是它携带的是合并的、经过 QA 的代码，这些代码旨在用于下一个错误修复版本，而不是下一个通用版本。

计划在当前维护的发布系列中发布的拉取请求在合并到 main 分支后会被反向移植到这些分支。在此过程中，它们在 GitHub 上被标记为 backport-v3.13.x、backport-v3.12.x 和类似标签。

例如，如果一个拉取请求被标记为 backport-v3.12.x，则意味着它已被反向移植，或至少被考虑反向移植到 v3.12.x 分支，以便在 3.12.x 版本中发布。

标签​

RabbitMQ 团队在 git 仓库中使用标签来为代码状态的快照命名：最重要的是，发布版本。通常，核心仓库和旨在与命名快照一起工作的插件仓库都会被标记。

例如，如果您正在使用 RabbitMQ 服务器版本 3.12.7，那么检查 git tag 的输出将产生

git tag
# omitted for brevity
# => v3.13.0
# => v3.12.13
# => v3.12.12

git checkout v3.13.0

此时，您可以按照插件文档中的说明继续编译插件。