提交拉取请求 - MariaDB.org

与许多开源项目一样，MariaDB 通过 GitHub 上的拉取请求接受贡献。因此，如果你想贡献，必须先在 GitHub 上创建一个账户。创建账户后，你可以按照以下步骤操作

首先你需要将代码获取到你的机器上。
```
git clone https://github.com/YOUR-USERNAME/server
```
使用 git clean dry run 选项检查是否有未跟踪的文件是一个好习惯。
```
git clean -dn
```
或者你可以使用 git clean -i 来交互式地指定要删除的内容。
如果有未跟踪或被忽略的文件，并且你确定它们可以被删除，如果你过去曾构建过 MariaDB 并最近更新了仓库，则应该从基本仓库中完全清除旧的构建产物（例如 cmake 配置的文件）。使用
```
git clean -dffx && git submodule foreach --recursive git clean -dffx
```
进入你的本地仓库目录，为你的修复创建一个开发分支并切换到该分支。
```
git checkout -b fix-bug-server 10.11
```

我们保证每个拉取请求都会得到回复。评审可能需要更长时间，具体取决于补丁的复杂性或开发人员的工作量。社区成员可以参与提供评论，但最终决定补丁是否接受或需要进一步改进的是主要评审人。

拉取请求许可

MariaDB 中的所有代码均来自以下来源之一

如果你想向 MariaDB 基金会提交代码，必须为你的工作提供共享版权。为此，MariaDB 基金会要求拉取请求必须在 BSD 新三条款许可或 MariaDB 贡献者协议下提交。这使我们能够将贡献回馈给 MySQL 等其他项目，否则将无法做到这一点。

在提交拉取请求之前，有必要确保你的 Fork 是最新的。要与上游同步，你需要跟踪上游仓库并在其之上进行 rebase。
```
git remote add upstream https://github.com/MariaDB/server.git
```
每当你想与上游合并时，首先获取所有更改，同时删除远程仓库上不再存在的任何远程跟踪引用，然后进行 rebase。这假设你自己在 10.11 分支上没有进行任何工作。
```
git fetch -p upstream
git checkout 10.11 && git rebase upstream/10.11
```
在上游进行 rebase 后，将更改推送到你的 GitHub 仓库很有用。
```
git push origin 10.11
```
如果你需要切换到不同的分支，例如 11.4，则需要创建一个派生自 upstream/11.4 的本地分支 11.4 并切换到新创建的分支。
```
git branch 11.4 upstream/11.4
git checkout 11.4
```
你可以在一行中完成上述操作
```
git checkout -b 11.4 upstream/11.4
```

在上游 rebase 主分支后，你也可以 rebase 你的错误修复分支。
```
git checkout fix-bug-server && git rebase 10.11
```
Rebasing 允许形成线性历史，并防止不必要的合并提交。我们倾向于尽可能避免合并提交，对于错误修复通常如此。
更新你的拉取请求时（如果你收到了评审人员要求进行更改的请求），不要创建新的拉取请求。相反，你可以在本地的错误修复分支上工作，实现建议的更改，为这些更改创建新的提交，最后你可以通过交互式地 rebase，将 N-1 个提交压缩到最初添加到拉取请求中的那个提交（应该被挑选）中。
```
git rebase -i HEAD~N
```
在本地完成更改后，使用 --force 选项将其推送到你的 GitHub 仓库。通过此步骤，你的拉取请求也会被更新。
```
git push --force origin fix-bug-server
```

标题行以大写字母开头。
标题长度应在 70 个字符左右，末尾不要加句号。“.”（句号）。
使用祈使句形式（不是“Cleaned”，而是“Clean up”）。
标题后留一个空行。
解释提交修复了什么以及为什么。关于“如何”的部分在代码中已经涵盖。仅当问题需要进一步上下文时才深入实现细节，尽管这些细节也应在代码注释中可见。在此处运用你的最佳判断。
尽量保持与你修改的文件中看到的相同的编码风格。