创建补丁
新的 aports 通常应放入 testing 仓库。经过合理的测试期后，如果软件包完整（例如，它有 init 脚本，它有可工作且合理的默认配置等）并且它有维护者，则可以将其移至 community 仓库。Main 仓库用于 Linux 系统的核心软件包或作为其他核心软件包的依赖项的软件包。Main 仓库中的软件包不能依赖于 community 或 testing 仓库中的软件包，而 community 仓库中的软件包不能依赖于 testing 仓库中的软件包。
目前有两种方式可以提交更改建议：通过 Gitlab 和通过邮件列表。
通过 Gitlab 提交补丁
设置
要在 Alpine Linux 的 Gitlab 实例 上提交补丁，您首先必须在此处创建一个帐户。建议现在设置一个 SSH 密钥，有关如何操作，请参阅 Gitlab 文档。
创建合并请求
现在您已完成设置，您必须 fork 您要贡献的仓库。例如，如果您要为 aports 打开合并请求，则必须 fork alpine/aports，如果您在操作时遇到问题，请参阅 Gitlab 文档。属于 Alpine Linux 的其他仓库位于 Alpine 组织 中。如果您已经有一个旧的 fork，请先克隆它，然后如下所示更新它。
fork 后，您可以像这样克隆仓库
git clone git@gitlab.alpinelinux.org:$USER/$REPO.git
将 $USER 替换为您的 Gitlab 帐户昵称，将 $REPO 替换为您要处理的仓库。现在您可以切换到另一个分支（例如，您要编辑的软件包的名称），使用
（如有必要，首先更新旧的 fork，请参阅下面的 变基）
git checkout -b pkgname
现在进行更改，然后使用以下命令推送
git push -u origin $branchname
Gitlab 将在您的终端中打印一个 URL 以创建合并请求。
修改合并请求的更改
如果审阅者要求更改，或者您注意到您的合并请求的更改应进行某些更改，则可以简单地将您的更改修改到正确的提交并强制推送。因此，如果您想更改分支尖端的提交，可以简单地执行
git commit --amend
如果您想更改不在分支尖端的提交，您可以执行
git commit --fixup $SHA1_OF_COMMIT_YOU_WANT_TO_FIX
之后，您必须强制推送才能更新您的合并请求
git push -f origin
基于 Alpine Linux 的 master 分支进行变基
最好始终与上游 Alpine Linux 仓库的状态保持同步，以确保以后不会发生合并冲突。为此，您首先必须添加一个新的 git 远程仓库，该远程仓库指向上游仓库（而不是您的 fork）
git remote add upstream https://gitlab.alpinelinux.org/alpine/$REPO
现在您可以使用以下命令获取所有更改
git fetch --all
然后您可以使用以下命令进行变基
git rebase
通过邮件列表提交补丁
补丁应使用 git 创建，并通过 git send-email（需要 git-email Alpine 软件包）提交到 alpine-aports 邮件列表。
仅使用 'git send-email' 提交最后一个提交
要将最后一个提交作为补丁提交到 alpine-aports 邮件列表
git send-email --to alpine-aports@lists.alpinelinux.org -1
git config sendemail.to alpine-aports@lists.alpinelinux.org
提交消息中的第一行将是主题，长描述（用空行分隔）将是电子邮件的正文。下面的示例显示
testing/packagename: new aport <- header https://example.com/packagename <- body wonderful package
请参阅 Development using git#Email_configuration 了解如何配置 SMTP 身份验证。
使用 'git send-email' 提交多个提交
如果您有多个提交，您可以创建一个包含补丁的目录并使用以下命令发送它们git send-email.
rm -Rf patches mkdir patches git format-patch -o patches origin git send-email patches --compose --no-chain-reply-to --to alpine-aports@lists.alpinelinux.org
您还可以使用以下命令为最后 x 个提交格式化补丁
git format-patch -x -o patches
这将为“patches”目录中的每个本地提交生成补丁并发送它们。使用 --no-chain-reply-to 以避免每个补丁都作为对上一个补丁的回复发送。
例如。
- [PATCH 0/m]
- [PATCH 1/m]
- [PATCH 2/m]
- ...
- [PATCH 2/m]
- [PATCH 1/m]
使用选项 --no-chain-reply-to，补丁将作为对第一封电子邮件（封面信，即 [PATCH 0/m]）的回复发送，并将使电子邮件线程更清晰。像这样
- [PATCH 0/m]
- [PATCH 1/m]
- [PATCH 2/m]
- ..
重新发送更新的补丁
有时补丁会因补丁中的小问题而被拒绝。不要在您的初始错误补丁之上发送增量补丁。相反，重新创建补丁并发送新的、修复后的补丁版本。（使用 git commit --amend 编辑本地提交）。
当您发送补丁的第二个版本时，请使用 --subject-prefix "PATCH v2" 来指示这是一个先前发送的补丁的新版本。您也可以使用 --in-reply-to <message-id>，其中 <message-id> 是请求重新发送的电子邮件的 ID。
您还应该写一个关于更改内容的注释。为此使用 --annotate，并将注释写在三个破折号“---”下，以便注释不包含在提交消息中。例如
... Subject: [PATCH v2] testing/mypackage: new aport https://example.com Example package --- Changes v1 -> v2: - removed depends - added zlib-dev to makedepends testing/mypackage/APKBUILD | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 testing/mypackage/APKBUILD ...
请注意，在“---”下方的注释将不会包含在提交消息中。