创建补丁
新的 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 以创建合并请求。
修改合并请求的更改
如果审阅者要求更改，或者您注意到您的合并请求的更改应该进行某些更改，您可以简单地将您的更改修改到正确的 commit 并强制推送。因此，如果您想更改分支顶端的 commit，您可以简单地执行
git commit --amend
如果您想更改不在分支顶端的 commit，您可以执行
git commit --fixup $SHA1_OF_COMMIT_YOU_WANT_TO_FIX
之后，您必须强制推送以更新您的合并请求
git push -f origin
基于 Alpine Linux 的 master 分支进行变基
最好始终与上游 Alpine Linux 仓库的状态保持同步，以确保稍后不会发生合并冲突。为此，您首先必须添加一个新的 git remote，它指向上游仓库（而不是您的 fork）
git remote add upstream https://gitlab.alpinelinux.org/alpine/$REPO
现在您可以使用以下命令获取所有更改
git fetch --all
然后您可以使用以下命令进行变基
git rebase
通过邮件列表提交补丁
补丁应该使用 git 创建，并使用 git send-email 提交到 alpine-aports 邮件列表（这需要 git-email Alpine 软件包）。
仅使用 'git send-email' 提交最后一个 commit
要将最后一个 commit 作为补丁提交到 alpine-aports 邮件列表
git send-email --to alpine-aports@lists.alpinelinux.org -1
git config sendemail.to alpine-aports@lists.alpinelinux.org
commit 消息的第一行将是 subject，长描述（用空行分隔）将是电子邮件的正文。下面的示例显示
testing/packagename: new aport <- header https://example.com/packagename <- body wonderful package
请参阅 Development using git#Email_configuration 了解如何配置 SMTP Auth。
使用 'git send-email' 提交多个 commit
如果您有多个 commit，您可以创建一个包含补丁的目录，并使用以下命令发送它们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 个 commit 格式化补丁
git format-patch -x -o patches
这将为目录 "patches" 中每个本地 commit 生成补丁并发送它们。使用 --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 编辑本地 commit）。
当您发送补丁的第二个版本时，请使用 --subject-prefix "PATCH v2" 来指示这是一个先前发送的补丁的新版本。您也可以使用 --in-reply-to <message-id>，其中 <message-id> 是请求重新发送的电子邮件的 ID。
您还应该写一个关于更改内容的注释。为此使用 --annotate，并将注释写在三个破折号 "---" 下面，这样注释就不会包含在 commit 消息中。例如
... 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 ...
请注意，"---" 下面的注释将不会包含在 commit 消息中。