Git 指南

本文档涵盖了 Rocky Enterprise Software Foundation (RESF) 如何在其生态系统中管理 Git 的使用，包括 RESF 及其像 Rocky Linux 这样的项目。它包含有关各种团队和社区如何与 Git 互动和协作的信息，以及期望和要求。

注意

使用 RESF 托管的 Git 服务须遵守 Rocky Git 贡献者协议

联系信息¶


所有者	发布工程 (SIG/Core) / 基础设施
Mattermost 联系人	`@label` `@mustafa` `@skip77` `@sherif` `@pgreco` `@neil` `@tgo`
Mattermost 频道	`~development` `~infrastructure`
IRC 频道	`#rockylinux-devel` `#rockylinux-infra`
IRC 联系人	`Sokel` `neil` `tg`

一般信息¶

Git 是 Rocky Linux 构建生态系统、RESF 项目的核心组成部分，因此也是分发和可用软件开发过程的一种模式。

Gitea 用于 RESF、其项目、其代码、镜像仓库以及潜在的其他组件。

GitLab 是目前用于存储大部分 RPM spec 文件、修补程序、用于包去品牌化/修改的配置以及一些脚本/实用程序的软件。除了 src-git 场景外，源代码通常不存储在此处。

GitHub 用于 RESF 和 Rocky Linux 项目组织，其中可能包含品牌信息、脚本/工具/实用程序或少量其他有用的代码（如 ansible）。也可能存在上游项目的 fork（如 mock），用于处理对 Fedora 项目（如 EPEL）的上游更改。

期望¶

本节将介绍使用 Git 服务的期望。

一般期望¶

大部分信息都在我们的 Git 贡献者协议 中涵盖，该协议通常涵盖 RESF Git 服务和 Rocky Linux GitLab。但是，我们在此处为所有读者重复这些信息。

强制执行审核 - 就像在 Rocky Linux Mattermost 聊天中一样，无论是在 Git issues 还是 Bug Tracker 中，都要注意您的语言和措辞。
必须上传一个有效的 GPG 密钥并用于签名您的提交 - 通常情况下，要求提交签名。预计大多数项目将禁用未签名的提交。
不要将 git 用作 issue tracker - Rocky Linux 的所有 issue 都应在我们的 Bug Tracker 中跟踪。在撰写本文时，会为构建 issue 打开 issue。
请勿在由您的雇主拥有的系统上执行工作或更改。
不鼓励创建个人项目（参见例外情况）
确保您的软件或工作遵循有效的开源许可证（参见上面的相关链接）

可以和不可以¶

以下是我们 Git 的可以和不可以列表，其中一些是上面或下面子节中的重复信息。它们放在这里是为了进一步强调。

可以

根据需要 fork 仓库并创建 pull request
确保引入 Git 服务的软件/源代码具有有效的开源许可证
上传有效的 GPG 密钥并签名您的提交

不可以

将任何 Git 服务视为 Rocky Linux issue tracker
在您的命名空间下创建个人项目（参见例外情况）
在由您的雇主拥有的系统上执行工作或更改

例外情况¶

在您的命名空间下创建个人项目的例外情况是，代码将以某种方式用于 Rocky 生态系统，无论是直接的还是间接的（例如，用于 people.rocky）。使用 Peridot 作为类似 COPR 的服务也是如此。

源代码（适用于 SIG 或其他软件）¶

待填充。

SIG 组 + 项目¶

本节涵盖 Rocky Linux Git 服务中存在的 SIG 组和项目。SIG 可能拥有 RPM spec、脚本，甚至自己的软件。下面的部分将介绍这些组和项目的格式和期望。

总体概述¶

SIG 是特殊兴趣小组。SIG 是 Rocky 社区内的小型群体，专注于少量问题或仅为提高对某个话题的认识或关注度而存在。本节不涵盖 SIG 存在的先决条件。

通常，SIG 最终可能拥有包含可以添加到 Rocky Linux 系统的包的仓库。但是，有些 SIG 的功能并非如此。在这种情况下，它们通常会在 Rocky Linux GitLab 中位于 SIG 组下方的部分。

SIG 始终会在 RESF Git 服务上有一个组织。

结构（打包）¶

以RPM 结构为指导，基本思路相同。可能不需要 patch 组，但可能有用。SIG 可以设置其组的示例可能如下所示：

.
└── SIG
    └── messaging
        ├── modules
        ├── rpms
        │   └── somemq
        └── somemq

在此示例中，软件 somemq 的源代码将位于 SIG 下方的 messaging 子组中。然后，该 SIG 该软件的 RPM spec 将按预期位于 rpms 下方。但是，您可以根据需要进一步组织。

.
└── SIG
    └── messaging
        ├── modules
        ├── rpms
        │   └── somemq
        └── sources
            └── somemq

这不是严格要求，但可能有利于组织。

访问 SIG 组¶

通常通过联系赞助商（如在 Account Services 中找到的）并请求访问成为 SIG 的一部分来获得 SIG 组的访问权限。一旦您被添加到该组以及 gitusers 组，您将能够在该 SIG 中进行工作。

其他组¶

其他组通常不会出现在 Rocky GitLab 实例中。相反，它们将（并且应该）存在于 RESF Gitea 实例中。这些组可能包含以下仓库：

一个团队的源代码
一个团队的工具或脚本集
其他杂项元数据

组的示例包括：

Infrastructure -> 此组包含与 rocky 基础设施相关的仓库
releng -> 发布工程仓库和代码
sig_core -> 核心特殊兴趣小组，专门用于与 Rocky Linux 开发和基础设施相关的代码和项目

RPM 系统¶

本节介绍 RPM 系统，例如导入、修补以及最终如何构建成二进制 RPM。这发生在 git.rockylinux.org 上。

当前 RPM 结构¶

当前的 RPM 结构设计用于允许编排器工具导入源，然后在需要时进行相应的修补。它还允许支持和管理具有所需 YAML 文件的 AppStream 模块。

有四个主要组：

original：包含来自 Rocky 的 RPM spec 数据，如发布版本和 logo。
staging：包含 staging 通道的 RPM spec 数据，例如测试工具的操作和功能是否正确，以及测试构建过程。
release：包含 release 通道的 RPM spec 数据，这将是用户将使用的实际发布版本。

.
├── original
│   ├── modules
│   ├── patch
│   └── rpms
├── release
│   ├── modules
│   ├── patch
│   └── rpms
└── staging
    ├── modules
    ├── patch
    └── rpms

每个组有三个子组：

modules 组用于存储包含 YAML 文件的仓库。YAML 文件定义了将在 AppStream 仓库中存在的模块。
patch 组用于存储 distrobuild 用于获取和修补或执行与 RPM 相关的其他任务的配置。
rpms 组用作修补（如果适用）后的 RPM spec 文件和修补程序的最终输出/导入，然后用于/用于构建 SRPM 并发送到 koji 进行构建。
src 组（虽然不是必需的）可以是包的源文件所在的位置，以帮助创建修补程序（如果需要）。

请注意，计划使用构建系统的 SIG 或项目应遵循此方法。

RPM 修补程序结构¶

对于修补程序配置，必须严格遵循布局，以确保 SPEC 文件或其源文件得到相应修改。以下是一个示例。

.
└── ROCKY
    ├── CFG
    │   └── browser.cfg
    └── _supporting
        ├── Bug-1238661---fix-mozillaSignalTrampoline-to-work-.patch
        ├── Bug-1526653---fix_user_vfp_armv7.patch
        └── firefox-rocky-default-prefs.js

在顶层，ROCKY 文件夹将包含两个附加文件夹：CFG 和 _supporting。

CFG 目录将包含以 .cfg 结尾的文件，这些文件告诉编排器要对输入的进行什么操作。

Action {
    file: "OriginalFile"
    with_file: "ROCKY/_supporting/RockyReplaceFile"
}

有关详细信息，请参阅我们的 Debrand HowTo 页面。

分支策略¶

通常在创建 patch 仓库时，main 分支应该包含所有内容。但是，在某些情况下这并不足够，尤其是在主要发布版本存在差异的情况下。以下是分支工作方式的一般思路/示例：

main 是在修补过程中始终使用的通用分支
r8 是 Rocky 8 的分支，专门用于修补对应的 8 的 RPM spec/修补程序
r9 将用于 Rocky 9
r9-beta 将用于 Rocky 9 beta
等等...

在实际的修补程序过程中，将首先解析并应用 main 分支，然后如果存在相应的 rX 分支，将接下来应用该分支。有时 main 分支可以为空，而您只有 rX 分支。这是可以接受的，并且仍然有效。

请注意，在此策略下，在大多数情况下不推荐合并分支。尽量将它们分开，只要有可能并且绝对需要。唯一应该合并或强制推送分支的情况是从 rXlh 到 rX-beta 或 rX-beta 到 rX。

提交潜在的修补程序¶

有几种方法可以提交修补程序来修复主分发版中的构建问题。本节将介绍一些提交修复请求以供审查的方法示例。

修补程序仓库不存在¶

如果某个包失败，或者您想提交一个修补程序，例如允许某个内容在另一个架构（例如 armv7/armhfp）上正确编译，或者您发现基础的一部分没有正确去品牌化，通常应该在我们的 Bug Tracker 上打开一个 bug 报告，并附带相关信息和日志。可以打开一个您命名空间下的项目，并在审查后最终转移到 staging。