13.2. GitHub、Git及相关主题
13.2.1. GitHub
Open MPI的Git代码库托管在GitHub上。
首先，您需要一个Git客户端。我们建议获取最新的可用版本。如果您的路径中没有
git命令，您可能需要下载并安装Git。ompi 是主要的 Open MPI 代码库，大部分活跃开发都在此进行。请使用 Git 克隆该仓库。注意必须使用
--recursive命令行选项，因为 Open MPI 使用了 Git 子模块：shell$ git clone --recursive https://github.com/open-mpi/ompi.git
请注意，Git原生支持多种形式的网络代理。如果您的网络设置需要使用网络代理，请参阅Git文档以获取更多详情。
13.2.2. Git提交：开源/贡献者声明
为了保持开源性质，所有提交到Open MPI仓库的新提交都必须包含Signed-off-by:行，表明提交者同意Open MPI Contributor’s Declaration。
提示
你可以使用-s选项在git commit时
自动将Signed-off-by:行添加到你的提交
信息中。
13.2.3. Git分支方案
通常，Open MPI在其Git仓库中有两种类型的分支：
main:所有活跃的开发工作都在
main分支上进行（包括新功能开发、错误修复等）。
发布分支的形式为
vMAJOR.MINOR.x（例如：v4.0.x，v4.1.x，v5.0.x）。.x后缀表示该分支用于创建 Open MPI vMAJOR.MINOR 系列中的所有版本。Open MPI社区会定期从
main分支创建新的发布分支。使用形如
vMAJOR.MINOR.RELEASE的Git标签来标识发布分支上创建官方Open MPI发布压缩包的特定提交点（例如v4.1.0、v4.1.1、v4.1.2等）。
一旦在main分支上修复了错误或实现了新功能，就会将其精选到相关的发布分支。
注意
对某些人来说可能显得奇怪，但Open MPI社区的开发模式不会直接将错误修复或新功能的PR提交到发布分支。相反，初始的错误修复/功能PR通常首先提交到main分支。
这有助于我们确保未来的版本（以main作为Git祖先）将包含错误修复/功能。
例如：
shell$ git checkout main
shell$ git pull --rebase
shell$ git checkout pr/bug-fix
# ... make changes / fix a bug / etc. ...
shell$ git add ...
shell$ git commit -s ...
shell$ git push myfork
此时，您需要从您fork的pr/bug-fix分支向Open MPI社区的GitHub仓库main分支创建一个PR（拉取请求）。与社区协作完成PR并合并后，您可以开启一个新的PR，将该错误修复的Git提交精选到每个相关的发布分支。
根据发布分支与main分支的偏离程度，在cherry-pick过程中可能需要一些移植工作。
例如，如果您在main分支上的错误修复仅包含一个Git提交哈希值123abc：
# Fetch all upstream git activity, including the merge of the "main" PR.
shell$ get fetch --all
# Check out the target release branch, and advance to the most recent commit.
shell$ git checkout v5.0.x
shell$ git pull --rebase
# Make a branch for your bug fix
shell$ git checkout -b pr/v5.0.x/bug-fix
# Cherry pick the commit from the "main" branch
shell$ git cherry-pick -x 123abc
# Push to your fork
shell$ git push myfork
Open MPI开发社区要求在发布分支上cherry-pick提交的提交消息中添加以下行：
(cherry picked from commit [git_hash_of_original_commit])
注意
注意使用-x选项来执行git cherry-pick。
该选项会自动在提交信息中添加(cherry picked from
...)这一行。
基本原理
Git实际上并不会在提交中存储任何关于Git cherry-pick操作的元数据。在提交信息中包含带有原始Git提交哈希值的标准化文本行，有助于Open MPI开发社区追踪发布分支上的提交来源，从而使我们能够检查所有相关提交是否已移植到指定的发布分支。
当您的提交准备就绪并推送到您的分支后，向目标发布分支发起一个拉取请求(PR)。
警告
GitHub PR CI任务会检查发布分支上的所有提交，确保包含(cherry picked from...)标记行。同时它还会验证该行中引用的Git哈希值确实存在于main分支上。
该检查确保在对应的main PR合并之前，不会向发布分支提交代码。
综上所述，有时在发布分支上确实需要一个非精选的提交。例如，有时发布分支的分化程度已经很高，导致该错误在main分支上不复存在。因此，将相关错误修复提交到main分支可能没有意义，甚至根本无法实现。
在这种情况下，向目标分支提交一个常规的拉取请求（提交内容中不要包含(cherry picked from ...)这样的行）。在拉取请求描述中，添加一行包含以下标记的内容：
bot:notacherrypick
这告诉GitHub CI作业，该PR包含的提交并非从main分支精选而来。
警告
bot:notacherrypick 应仅在绝对必要时使用。这不能作为绕过先向main提交PR流程的借口。
13.2.4. 持续集成(测试)
Open MPI 社区通常运行两种类型的测试：
针对每个拉取请求(PR)进行一系列测试(持续集成/CI)。这些测试混合使用了GitHub Actions和其他CI系统(例如Jenkins)。测试示例包括(但不限于):
检查每个Git提交中的无效电子邮件地址
检查每个Git提交是否包含
Signed-off-by行检查发布分支上的提交是否包含 cherry-pick 通知
构建并发布文档
在各种环境中构建Open MPI并使用该安装运行健全性测试
通过MPI测试工具(MTT)进行每日测试。