使用 Git 和 GitHub
本页面介绍我们在 RabbitMQ 项目中使用 Git 的方式。
概述
Git 是一个快速、强大的分布式源代码管理系统。它有大量的教程。
Team RabbitMQ 使用 Git 来管理我们几乎所有的源代码。
RabbitMQ 源代码仓库托管在 GitHub 上。本网站上的各个项目页面通常会指导您需要检出的特定模块组合。
本网站本身也开源并托管在 GitHub 上。
分支策略：每个问题一个分支
RabbitMQ 在开发 RabbitMQ 代码时使用“每个问题一个分支”的技术，其中每个功能或错误修复都在自己的分支上使用
git checkout -b
并在通过 QA 后才合并到 `main` 或 `stable` 分支。分支遵循 `repository-name-NN` 的模式，其中 repository-name 是提交问题的 GitHub 项目的名称（例如 `rabbitmq-dotnet-client`），NN 是 GitHub 问题编号。在问题所属的仓库名称前面加上前缀的目的是，一个问题可能需要对多个项目进行更改。对于原始 Bugzilla 跟踪器（不公开）中的问题，也有名为 `bugNNNNN` 的分支。
拉取请求和评审/QA 流程
准备好进行评审和/或 QA 的分支应作为拉取请求提交。然后会在评论中提供反馈。收到反馈后，更新原始分支并推送到 Git：GitHub 会负责更新拉取请求。然后流程继续，直到拉取请求被合并或关闭（例如，因为在尝试实现某个功能后被拒绝）。
如果是一个不涉及与最新稳定版不兼容更改（即不更改 Mnesia 模式或节点间通信）的错误修复，则拉取请求必须针对 `stable` 分支；对于其他所有情况，则针对 `main` 分支。
主分支
默认仓库分支包含所有已 QA 并计划在下一个功能版本中发布的已 QA 工作。
通常，您可以通过跟踪感兴趣的 RabbitMQ 仓库的 `main`（默认）分支来跟踪已 QA 的开发工作。
旨在发布到当前维护的发布系列中的拉取请求（例如 3.11.x）会被反向移植到特定于发布系列的分支。
发布系列分支
对于当前维护的每个发布系列，还有一个单独的分支。这些分支以系列命名：`v3.13.x`、`v3.12.x` 等。
它的作用与 `main` 分支相同，不同之处在于它包含已合并、已 QA 的代码，用于下一个错误修复版本，而不是下一个通用版本。
旨在发布到当前维护的发布系列中的拉取请求，在合并到 `main` 分支后会被反向移植到这些分支。在此过程中，它们会在 GitHub 上被打上 `backport-v3.13.x`、`backport-v3.12.x` 等标签。
例如，如果一个拉取请求被标记为 `backport-v3.12.x`，这意味着它被反向移植（或至少考虑反向移植）到 `v3.12.x` 分支，以便在 3.12.x 版本中发布。
标签
Team 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
此时，您可以按照插件文档中的说明继续编译插件。