如何为mathlib做出贡献#

这里有一些提示和技巧使贡献过程尽可能顺利。

• 使用祖利普到在工作之前和工作期间讨论你的贡献。
• 遵守指导方针：
  • 这个样式指南供贡献者使用。
  • 解释命名约定.
  • 这个文档指南.

一旦你有了想要贡献的代码，你应该打开一个PR。

使用mathlib#

我们使用吉特管理和版本控制马特里布.这个主人branch是mathlib的“生产”版本。重要的是，主分支中的所有内容编译时都没有错误，并且没有对不起的第条。为了确保这一点，我们只将更改提交给主人已经通过自动化持续集成（“CI”）测试，并且已经得到mathlib维护人员的批准。

当你为马特里布，您应该在其他分支上执行此操作。你可以在自己的叉子里做这件事马特里布储存库，或者您可以在Zulip上介绍自己，并请求对非-主人mathlib存储库的分支，你可以选择制作自己的线程介绍自己，或要求进入这个主题.请在您的请求中包含您的GitHub用户名（并使用个人设置面板将此用户名添加到您的Zulip配置文件中）。有礼貌的做法是在分支名称前面加上用户名，这样我们就更容易清理混乱。（一旦您发出拉取请求，我们将要求您从mathlib存储库的一个分支进行请求，而不是从你自己的分叉，因为CI这样做效果更好。）

典型工作流程：

• 首先，您需要mathlib的本地副本。
• 如果您要求写访问权限（上面推荐），您可以使用https://github.com/leanprover-community/mathlib4.否则，你需要去https://github.com/leanprover-community/mathlib4然后单击右上角的“Fork”，创建自己的存储库分支。你的叉子在https://github.com/USER/mathlib4网站.
• 现在制作存储库的本地克隆。

  吉特 克隆 https（https）://github.com网站/精益校准仪-社区/mathlib4.吉特
  光盘 数学实验室4
  湖 可执行文件 隐藏物 得到
  

• 上述步骤只需执行一次（而不是每次都执行一次）。
• 现在，每次您想对mathlib进行新的更改时，请创建一个新分支：

  吉特 转换 -c（c） 我的新分支（_N）   # 这个 创建 一 新的 分支 和 开关 到 它
  

  如果您要求写访问权限，可以将新分支推送到mathlib具有一些优势（见下文）。
• 有时您可能不想创建新分支，而是在分支上工作其他人创建的，或您从其他计算机创建的。在这种情况下，您需要使用git交换机他们的新分支（注意没有-c（c）此处）。
• 进行本地更改，例如使用精益扩展使用Visual Studio代码。
• 使用提交更改git提交-a（或通过VS Code接口）。
• 如果您想在本地编译所有内容以检查您没有破坏任何内容，请运行湖泊建造。如果修改了导入层次结构中的下层文件，这可能需要很长时间。也可以让我们的中央CI服务器通过推动您的更改来为您实现这一点。
• 如果创建了新文件，请使用脚本/mk_all.sh.
• 为了将更改推回到github上的存储库，请使用

  吉特 推
  

  如果这表示远程未配置，请按照吉特然后跑

  吉特 推 --设置流源my_new_branch
  

• 如果你在干活马特里布存储库而不是您自己的分叉，此时，持续集成将自动启动。您可以通过访问查看输出https://github.com/leanprover-community/mathlib4/tree/my_new_branch（如果一切正常，则该行上会有一个绿色的勾号，用于描述最近的提交，否则，如果CI仍在工作，则显示黄色圆圈；如果出现问题，则显示红十字。单击红十字查看详细信息。）您还可以通过安装来在命令行上检查CI状态轮毂和运行集线器状态.
• CI完成后，您可以运行lake exe缓存获取下载编译好的olean。

发出拉取请求（PR）#

一旦您对本地更改感到满意，就可以提出请求了。

• 如果您还没有请求对mathlib存储库的非主分支进行写访问，请过来https://leanprover.julipchat.com/，自我介绍，并请求此许可。

• 将更改推送到主存储库上的分支（如果它们还没有出现）。

• 如果你做了很多更改/添加，那么试着做很多包含小的、独立的部分的PR；一般来说，越小越好！这有助于你在进行过程中获得反馈，并且更容易审查。这对新贡献者来说尤其重要，因为它可以防止浪费精力。

• 公关的标题和描述应遵循我们的提交约定.

公关的生命周期#

我们使用GitHub“标签”来管理审查。（标签只能由“GitHub合作者”编辑，这与“请求写访问权限的人”大致相同。）

在PR的主页面右侧，应该有一个带有面板“审阅者”、“受让人”、“标签”等的侧栏。单击“标签”标题以在当前项目中添加或删除标签。

最重要的标签是“等待评论”和“等待作者”。如果你的公共关系建立（有一个绿色复选标记），并且你用“等待审查”，可能有人会在几天内“审查”它（取决于公关的规模；较小的公关会得到更快的回应）。审阅者可能会留下评论并将标签更改为“等待作者”。您应该解决每个评论，在问题解决后单击“解决对话”按钮。理想情况下，每个问题都可以通过新的提交来解决，但这里没有硬性规定。一旦实现了所有请求的更改，您应该将标签更改回“等待审阅”以重新开始该过程。

经过一些迭代后，审阅者将“批准”请购单，“准备合并”标签将自动应用于请购单博尔斯将从这里取走它。（参见在这里有关bor的更多详细信息。）在对bors做出适当回应（如有必要）后，PR将被添加到“合并队列”。合并队列会自动清除，但这需要一定的时间，因为它需要构建mathlib的分支。

以下是一些其他常用标签：

• 一“WIP”（=进行中的工作）公关仍然需要一些基础工作（例如，它可能仍然包含对不起的s） 在被审查之前。如果你想宣布你正在做你希望很快完成的事情，请发布WIP。

• 一“RFC”（=征求意见）是关于可能有争议或需要专家决定的变更的公关是否继续。

• 您可以添加“等待-CI”，这将暂时隐藏主审核队列上的请购单。CI完成后，此标签将自动删除。

• 考虑添加“需要帮助”直接征集捐款的标签。

• 这个“被其他-PR阻止”标签意味着在解决这个问题之前，应该解决一些特定的其他PR。要将“blocked-by-ther-PR”标签添加到您的PR中，请在PR注释中包含依赖项的PR编号（遵循注释中隐藏的示例），以便其他人可以一目了然地看到哪些PR应该首先进行审查。该标签将由机器人自动添加，并在合并其他请购单时自动删除。

• 这个容易的标签应用于标记可立即批准的请购单。维护人员和审查人员通常首先查看简单的PR，以保持队列流畅。简单的PR通常会添加一个引理、更正文档中的拼写错误或类似内容。如果你怀疑你的公关是否微不足道，你不应该加上这个标签。特别是，公关通常是不如果diff超过25行，则很容易添加任何定义或新文件，或添加任何简单与现有的引理或实例不直接类似简单引理或实例。

处理合并冲突#

由于多人并行处理mathlib，因此可能有人对主人这与你在公关上提议的改变相冲突。如果你的公关发生了这种情况，请检查本GitHub教程如何使用联机工具解决合并冲突。