使用 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，等等。

它与main分支的作用相同，只是它包含已合并、已通过 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

此时，您可以按照插件文档中介绍的方法继续编译插件。