Git 使用指南

本文档介绍了 Rocky 企业软件基金会 (RESF) 如何在其生态系统中处理 Git 的使用，包括 RESF 及其项目（如 Rocky Linux）。它包含有关各个团队和社区如何与 Git 交互和协作的信息，以及期望和要求。

联系信息¶


所有者	发布工程 (SIG/核心)/基础设施
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 规范文件、补丁、用于软件包去品牌化/修改的配置以及一些脚本/实用程序的软件。通常源代码不会存储在此处，除非是 src-git 场景。

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

期望¶

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

一般期望¶

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

实施审核 - 与 Rocky Linux Mattermost 聊天一样，在 Git 问题或 Bug Tracker 中注意您的语言和措辞非常重要。
必须上传有效的 GPG 密钥并用于签署您的提交 - 一般建议签署提交。预计大多数项目都会禁用未签名的提交。
不要将 git 视为问题跟踪器 - Rocky Linux 的所有问题都应在我们的 Bug Tracker 中进行跟踪。在撰写本文时，已为构建问题打开了问题。
不要在您雇主拥有的系统上执行您的工作或更改。
不鼓励创建个人项目（请参阅例外情况）
确保您的软件或工作具有有效的开源许可证（请参阅以上相关链接）

应该做和不应该做¶

以下是我们 Git 中应该做和不应该做的事情列表，其中一些内容是在本小节之前或之后重复的信息。将它们放在此处是为了进一步强调。

应该做

在需要时分叉存储库并创建拉取请求
确保引入 Git 服务的软件/源代码具有有效的开源许可证
上传有效的 GPG 密钥并签署您的提交

不应该做

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

例外情况¶

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

源代码（针对 SIG 或其他软件）¶

待补充。

SIG 小组 + 项目¶

本节介绍 Rocky Linux Git 服务中存在的 SIG 小组和项目。SIG 可能具有 RPM 规范、脚本，甚至他们自己的软件。以下部分将介绍这些小组和项目的格式和期望。

一般概述¶

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 规范将按预期位于rpms下。但是，您可以根据需要进一步组织此内容。

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

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

访问 SIG 小组¶

通常通过联系赞助商（在帐户服务中找到）并请求访问权限以成为 SIG 的一部分来获得 SIG 小组访问权限。将您添加到小组以及gitusers小组后，您将能够在 SIG 中工作。

其他小组¶

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

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

小组示例包括

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

RPM 系统¶

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

当前 RPM 结构¶

当前的 RPM 结构旨在允许协调程序工具导入源代码，并在需要时相应地对其进行修补。它还允许 AppStream 模块得到支持，并通过其所需的 YAML 文件进行管理。

有四个主要小组

original：包含来自 Rocky 的 RPM 规范数据，例如版本和徽标
staging：包含用于暂存通道的 RPM 规范数据，例如测试工具的正常运行和功能，以及测试构建过程。
release：包含用于发布通道的 RPM 规范数据，这将是用户实际使用的版本。

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

每个组包含三个子组

modules 组用于存储包含 YAML 文件的仓库。YAML 文件定义了 AppStream 仓库中存在的模块。
patch 组用于保存 distrobuild 的配置，以便其在与 RPM 相关时进行补丁或执行其他任务。
rpms 组用作 RPM 规范文件和补丁的最终输出/导入，在打补丁（如果适用）之后，然后用于/选取构建 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 如何操作页面中进行更详细的说明。

分支策略¶

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

main 是在打补丁期间始终使用的通用分支
r8 是 Rocky 8 分支，专门用于为 8 打补丁相应的 RPM 规范/补丁
r9 将用于 Rocky 9
r9-beta 将用于 Rocky 9 beta
等等…

在实践中，当补丁过程发生时，首先解析并应用 main 分支，然后如果存在相应的 rX 分支，则会接下来应用该分支。也有一些情况，main 可以为空，并且您只需使用 rX 分支。这是可以接受的，并且仍然有效。

请注意，使用此策略，在大多数情况下不建议合并分支。尽量使它们尽可能地保持分离，并在绝对必要时进行分离。仅当从 rXlh 转到 rX-beta 或 rX-beta 转到 rX 时，才应合并或强制推送分支。

提交潜在的补丁¶

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

补丁仓库不存在¶

如果某个包失败，或者您希望提交补丁（例如，允许某些内容在其他架构（例如 armv7/armhfp）上正确编译），或者您发现基础中的一块没有正确地去除品牌，通常应该在我们的 Bug Tracker 中打开一个错误报告，并提供相关信息和日志。可以在您的命名空间下打开一个项目，并在审查后最终将其转移到 staging 中。