为 PEFT 做贡献

我们很高兴接受对 PEFT 的贡献。如果您计划贡献代码，请阅读本文档，以使流程尽可能顺利。

安装

对于 PEFT 的代码贡献，您应该选择“source”安装方法。

如果您是创建 pull request 的新手，请遵循 GitHub 的 创建 pull request 指南。

测试和代码质量检查

无论贡献类型如何（除非仅与文档有关），您都应在创建 PR 之前运行测试和代码质量检查，以确保您的贡献不会破坏任何内容并符合项目标准。

我们提供了一个 Makefile 来执行必要的测试。运行以下代码进行单元测试

make test

运行以下命令之一，以仅检查或检查并修复代码质量和风格

make quality  # just check
make style  # check and fix

您还可以设置 pre-commit 以作为 Git 提交钩子自动运行这些修复。

$ pip install pre-commit
$ pre-commit install

运行所有测试可能需要几分钟，因此在开发过程中，仅运行特定于您更改的测试可能更有效

pytest tests/ -k <name-of-test>

这应该会更快完成并允许更快的迭代。但是，您仍然应该在创建 PR 之前运行整个测试套件，因为您的更改可能会意外破坏乍一看似乎无关的测试。

如果您的更改特定于硬件设置（例如，它需要 CUDA），请查看 tests/test_gpu_examples.py 和 tests/test_common_gpu.py，看看在那里添加测试是否有意义。如果您的更改可能会影响模型的保存和加载，请使用 --regression 标志运行测试以触发回归测试。

在您处理 PR 时，可能会发生由于合并了其他更改而导致底层代码库发生更改的情况。如果发生这种情况——尤其是在存在合并冲突时——请使用最新更改更新您的分支。这可以是合并或变基，我们将在 PR 准备就绪后进行 squash 和 merge。

PR 描述

打开 PR 时，请提供您建议的更改的清晰描述。如果它与其他 issue 或 PR 相关，请引用它们。提供良好的描述不仅可以帮助审阅者更好更快地审阅您的代码，还可以稍后用作提交消息的基础，这有助于项目的长期维护。

如果您的代码进行了一些重要的更改，那么在代码中添加注释来解释这些更改也是一个好主意。例如，如果您不得不多次迭代您的实现，因为最明显的方法不起作用，那么这很好地表明需要代码注释。

Bug修复

请描述导致 bug 的情况。如果存在现有 issue，请链接到它（例如，“Resolves #12345”）。

理想情况下，当提供 bugfix 时，应附带一个针对该 bug 的测试。该测试应该在当前代码中失败，并在 bugfix 中通过。在测试中添加引用 issue 或 PR 的注释。没有测试，将来更难防止回归。

添加新的微调方法

新的参数高效微调方法一直在被开发出来。如果您想向 PEFT 添加一种新的且有前景的方法，请按照以下步骤操作。

1. 在您开始实现新方法之前，请打开一个 GitHub issue 并提出您的建议。这样，维护人员可以给您一些早期反馈。
2. 请添加该方法的来源链接（通常是论文）。应提供一些证据表明人们对使用该方法有普遍兴趣。我们不会添加新近发布但没有证据表明有需求的的新方法。
3. 在实现该方法时，查看已有的现有实现作为指南是有意义的。此外，在构建代码时，请从其他 PEFT 方法中汲取灵感。例如，如果您的方法类似于 LoRA，则以类似的方式构建代码甚至在有意义的地方重用某些函数或类是有意义的（一些代码重复是可以的，但不要过度）。
4. 理想情况下，除了新方法的实现之外，还应该有示例（notebooks、scripts）、文档和广泛的测试套件，以证明该方法适用于各种任务。但是，这可能更具挑战性，因此只提供实现和至少一个工作示例是可以接受的。文档和测试可以在后续 PR 中添加。
5. 一旦您有了似乎可以工作的东西，即使它还不是可合并状态，也不要犹豫创建草稿 PR。维护人员很乐意在整个过程中为您提供反馈和指导。

添加其他功能

最好您首先在 GitHub 上打开一个 issue，并提出添加新功能的建议。这样，您可以与维护人员讨论在花费太多时间实现该功能之前，添加该功能是否有意义。

新功能通常应附带测试和文档或示例。没有后者，用户将很难发现您的酷炫新功能。

对代码的更改应以向后兼容的方式实现。例如，在合并功能后，现有代码应继续以相同的方式工作。