使用 Knative 入门开源 - 第 1 部分：开源简介

发布日期：2023-07-11 ,  修订日期：2024-01-17

使用 Knative 入门开源 - 第 1 部分：开源简介

作者：Calum Murray @ Red Hat 软件工程实习生，和 Leo Li @ Red Hat 软件工程实习生

欢迎回到本入门博客系列！在这篇文章中，我们将介绍开源：什么是开源，为什么你应该关注它，以及如何参与其中。

如果您已经有丰富的开源经验，您可以完全跳过这篇文章，直接跳到下一篇文章，我们将介绍如何为在 **Knative** 上工作设置您的开发环境。但是，如果您是开源新手，对了解更多信息感兴趣，或者想复习一下，那么我们期待与您一起讨论开源的什么、为什么以及如何！

什么是开源？

那么，什么是开源？开源背后的关键概念是所有源代码都公开可用：任何人都可以阅读它，修改它，改进它，并根据自己的意愿分发它 [1].

类似于开源软件，还有自由软件（在用户自由方面是免费的 - 就像言论自由，而不是免费食物），它与开源软件的主要区别在于商业关注度较低 [2]。虽然开源软件和自由软件之间存在重要的哲学差异，但我们不会在这篇文章中深入探讨这些差异，因为这篇文章旨在提供更实用的指南。

您可能已经使用过许多流行的开源软件，无论您是否知道它是开源的。例如，您的大部分浏览器可能是开源的！如果您使用的是 Firefox，那么您的浏览器（减去 DRM 代码）是开源的。如果您使用的是基于 Chromium 的浏览器，如 Google Chrome 或 Microsoft Edge，那么顾名思义，您的浏览器是基于开源项目 Chromium 的，但您的浏览器也包含专有组件。

此外，即使您不亲自使用 Linux 操作系统，您可能也至少听说过这个流行的操作系统。如果您使用的是 MacOS，那么您的操作系统与免费开源项目 FreeBSD 相关，尽管 MacOS 中也内置了许多专有（非开源）软件。因此，您的操作系统很有可能至少包含一些开源代码！

此外，既然您正在阅读这篇文章，您可能之前就编写过程序。这意味着您可能使用过开源软件，因为大多数编程语言，如 Python、Go、Rust 和 Java 都是开源的。

开源是一种庞大、流行且创新的构建和共享软件的方式。重要的是，它也是一个您可以参与其中的过程！

为什么您应该参与？

既然我们知道了什么是开源软件，以及您可能遇到的开源软件的示例，那么您为什么要参与开源呢？好吧，您可能想参与开源有很多不同的场景，所以让我们讨论其中的一些场景以及参与带来的好处。

一个非常常见的场景是，您是某款软件的用户，并且想添加一个功能或修复一个困扰您的 bug。因此，您可以通过添加该新功能或修复 bug 来为项目贡献代码，或者您可以通过简单地请求功能或报告 bug 来为项目贡献代码（没错，报告 bug 也是一种贡献方式！）。另一个常见的场景是，您相信某个软件项目，并且想成为社区的一部分，并以更长远的方式致力于改进该软件。另一种常见的状况是，您想通过在公共场合与其他有才华的人一起工作，扩展您的职业生涯，建立人脉关系和提升技能。

无论您选择参与开源项目或社区的原因是什么，许多好处都是一样的。主要包括：

1. 有机会成为一个充满活力的社区的一份子，该社区积极协作，共同打造最棒的软件。

2. 有机会了解不同的技术并处于创新的前沿。许多创新都始于开源项目。

3. 您将能够看到您的贡献对一个可能拥有非常多用户的大型项目产生影响（例如，Knative 的一个代码库大约有 1000 万次下载），这会让您感觉非常有成就感。

话虽如此，您正在阅读这篇文章的事实意味着您可能已经想要参与一个开源项目（希望是 **Knative**！），所以让我们深入了解一些您可以做出贡献的不同方式。

贡献类型

您可以对开源项目做出很多类型的贡献，通常情况下，所有贡献都受欢迎！请记住，**不同的社区对如何做出贡献以及对哪些贡献（如果有）接受会有不同的指南**。在开始贡献之前，请务必先与社区联系，以确保您是积极贡献，而不是浪费您和他们的时间。对于某个特定项目，您通常可以在代码库的 `README.md` 文件或 `CONTRIBUTING.md` 文件中找到贡献指南，尽管它也可能位于项目的网站上。如有疑问，请咨询社区！有了这个注意事项，让我们讨论一些常见的贡献方式。

创建问题

参与开源社区的一种很棒的方式是在 GitHub/GitLab 或社区使用的其他平台上创建 "issues"。例如，Knative 使用 GitHub 来跟踪 issues。issue 可以是 bug 或功能请求。所以，如果你在使用某个开源项目时遇到了 bug，可以创建一个 issue 并报告它！类似地，如果你想添加某个功能，也可以创建一个 issue 提出请求。虽然不能保证项目维护者会为你修复 issue，但他们通常会尽力尝试。这是参与项目的好方法，因为它可以让社区更好地了解像你这样的用户对项目的看法以及你遇到的问题。

Issue 分类

许多开源项目都会收到大量的 issues，给维护者带来大量的分类工作。但好的一面是，这对你来说是一个开始参与项目的好方法，维护者会非常感谢你的付出。

为了帮助分类 issues，你可以尝试重现 bug 报告，确保它确实是 bug，并帮助验证为 bug 做出的任何修复。你也可以阅读功能请求和提案，提出问题，并对你喜欢的/不喜欢的方面提供反馈，以及你是否认为该功能会改进项目。

编写文档

参与开源项目的另一种很棒的方式是为项目贡献文档。例如，如果你想为 Knative 做贡献，你可以尝试修复开放的文档 issue。随着软件的不断发展，文档往往落后。为了使项目更易于使用，人们积极参与文档更新至关重要。这也是学习更多项目技术细节的好方法，因为解释概念可以提高你对它们的理解。

参加社区活动和会议

中大型项目（以及一些小型项目）往往会举办会议和社区活动。这是一个与社区更多人交流并分享想法的好机会。例如，在 Knative 中，工作组每周和每两周都会举行会议，各种贡献者会在会议上讨论他们的工作，并请求对他们提出的功能进行反馈。我们非常欢迎你参加这些会议，它们是了解社区动态和项目发展方向的好方法。要了解更多关于 Knative 工作组会议的时间，请查看社区日历.

审查 PR

技术性更强的贡献是审查pull requests (PRs)。在 GitLab 上，它们也被称为 Merge Requests (MRs)。如果你之前没有听说过 PR，它本质上是让某人请求对项目代码进行一组更改的方式。因此，必须仔细审查这些更改，以确保它们是正确的并且正常工作。虽然如果你没有为项目贡献过很多代码，可能很难完全理解代码中的所有内容，但你仍然可以留下关于代码的评论和问题，试图提高更改的整体质量。但是，如果你真的不理解代码，你可能更有用的是验证更改是否有效。如果一切正常，请留下评论以说明这一点。否则，请留下评论，让 PR 作者知道他们需要修复一些东西。

贡献代码

也许你所能做出的最技术性的贡献就是贡献代码。这是本文的其余部分以及本博客系列的其余部分将重点关注的内容，因为其中涉及很多内容！但不要害怕，花点时间，你很快就会对进行代码更改并将其贡献回社区感到舒服。

如何贡献代码

在我们深入探讨如何贡献代码的细节之前，让我们花点时间看一下这个过程的整体情况。贡献的第一步是拥有一些你想更改的东西。也许它是一个新功能，也许它是一个 bug 修复，或者也许它别的东西。一旦你知道了你想做什么，最好与社区/项目维护者联系，以确保他们希望你进行你想要进行的更改。如果他们同意你提出的更改，就可以开始编码了！你将在你的仓库分支上创建一个新分支，然后编写一些代码。当你的代码工作时，你将用你的更改打开一个 PR。在你处理这些更改并让你的 PR 被审阅者批准后，你的工作就完成了，你的代码将被合并！（合并意味着将你的更改与代码库的主代码合并，以便每个人都可以使用它们）。这种流程可以在下面的图表中看到。

现在，如果你不熟悉这个过程，它可能感觉非常混乱。所以，为了进一步澄清，让我们分解每个部分并详细讨论它们。

提出更改

这个过程的第一步是提出更改。如果你想添加一个新功能，这一步非常重要，因为社区可能实际上并不想要你想要的功能，或者可能想要的功能与你的设想不同。在这两种情况下，如果你在提出功能之前就开始编码，你会浪费很多时间。不同的社区在提出和接受更改方面有不同的做法，所以尝试找出你的目标社区是如何做到的（这通常可以在 CONTRIBUTING.md 中找到，也可以通过查看仓库周围看看其他人正在做什么，或者在项目网站上找到）。例如，在 Knative 中，我们使用 GitHub Issues 提出新功能和报告 bug，并通过添加 triage/accepted 标签来批准它们。此外，对于大型功能，我们要求在 issue 旁边创建功能提案文档。但是，对于非常小的功能，比如修复开发人员文档，你也可以跳过这一步，只需通过创建 PR 来进行更改。

在你提出一个新功能或报告一个 bug 之前，尝试**搜索**社区用来跟踪 issues 的平台，看看是否有重复的 issue。如果已经存在并且已经被批准，那就太好了！你可以继续并开始执行流程的下一步。如果它存在但**尚未被批准**，你可以随时**评论 issue**，以表明你也有遇到过这个 bug，或者想要这个功能。最后，如果它**还不存在**，那么你应该**提出**这个功能或**报告**这个 bug。尝试在你的提案/bug 报告中尽可能多地包含细节，这将加快流程。无论你的更改是在之前提出的还是你亲自提出的，一旦它被批准，你就可以继续执行下一步了！

编写你的更改！

一旦你的提案被接受，就可以编写你的更改了。在本节中，我们不会花太多时间讨论如何编写代码本身（但如果你有兴趣了解如何编写 Knative 代码，请务必查看本博客系列的其余部分！）。相反，我们将重点关注编写代码时应该遵循的所有流程。通常，你将经历的编写更改的流程是

1. 为项目创建分支并将其克隆到本地

2. 创建一个分支

3. 提交

4. 创建一个 PR

5. 请求审查

6. 根据要求进行更改

7. PR 被批准。

8. 你的代码被合并了！

首先，你应该通常在一个项目的 fork 上工作。你可以将 fork 视为仓库的个人副本，你在其中拥有权限进行任何你想要的更改。这与主项目仓库不同，在主项目仓库中，你可能没有更改代码的权限。要在 GitHub 上创建 fork，你可以按照这些说明。要在 GitLab 上创建 fork，你可以按照这些说明。这里一些重要的术语是，你 fork 的仓库通常被称为 "上游" 仓库，而我们将你的 fork 称为 "origin"，因为这通常是你的本地 git 远程仓库的设置方式。为了轻松地克隆 fork 的仓库并正确设置 git 远程仓库，可以使用 git clonefork 命令，该命令可以从这里安装。或者，你可以自己使用git clone 和git remote 命令来配置你 fork 的本地副本。请注意，你将希望为上游仓库添加一个远程仓库，并且该远程仓库通常被称为 "upstream"。该远程仓库将用于将你的 fork 与上游项目中的任何更改保持同步。要手动克隆它，可以运行 git clone <url_of_your_fork>。接下来，要手动添加上游远程仓库，可以 cd 到新克隆的仓库，然后运行 git remote add upstream <url_of_upstream_repo> && git remote set-url --push upstream no_push。要获取你的 fork 和上游远程仓库的 url，请导航到每个仓库，并查找 GitHub 上显示 "Code" 的按钮，或 GitLab 上显示 "Clone" 的按钮。如果你单击此按钮，你应该会看到一个 URL，你可以将其复制。

一旦你有了 fork，将其克隆到本地，并正确设置了远程仓库，你应该检出一个新分支来进行更改。如果你不确定分支是什么以及如何创建分支，我们建议阅读这篇文章。我们还建议你将更改放在主分支之外的单独分支上，并保持主分支与上游主分支同步。这样，你就可以轻松地将任何未来的更改获取到你的 fork 中，因为它们将在主分支上共享相同的历史记录。要将你的 fork 的主分支与上游主分支同步，可以使用GitHub UI/GitLab UI并将这些更改拉取到你的本地主分支，或者可以运行 git checkout main && git pull upstream main（假设你尚未对主分支进行任何提交），然后将主分支推送到你的 origin。为了轻松地将你的本地主分支和 origin 的主分支与上游主分支同步，可以使用 git sync 命令，该命令可以从这里安装。

现在您已经在自己的 fork 中的一个分支上工作了，是时候编写您的更改了！在编写代码时，请记住项目代码风格。如果所有变量都使用 camelCase，那么您的变量名也应该使用 camelCase。如果有处理错误的通用方法，那么您应该以相同的方式处理错误。如果有大量的单元测试，那么您应该对更改进行单元测试（关于 Knative 中测试的更多信息将在后面的博文中介绍）。如果其他人无法区分您编写的代码与其余代码，那么您在遵循项目的风格方面做得很好。以下是您在编写代码时需要牢记的一些有用内容：

1. 变量、函数和类命名约定

2. 项目使用的代码格式/自动格式化程序

3. 是否存在提交消息约定？

4. 文件命名约定

5. 包导入规则

6. 包安装策略（检查是否存在策略，或者是否可以安装您需要的任何内容）

当您感觉自己取得了一些进展或更改完成时，请务必进行提交。有关提交的更多信息，请阅读 此处。Git 提交需要一个消息，因此请尝试提供一些信息，因为这将使其他人更容易理解您的更改。例如，“worked on bug fix” **不是一个好的提交消息**，而“added try catch block to prevent crash” 则更好，因为它 **描述了您所做的更改**。

创建 PR/MR

您可能希望打开 PR/MR 的两种情况。第一种情况是您认为您的更改已完成，并且已准备好合并到项目中。第二种情况是您已经取得了一些进展，但尚未完成，并且希望获得对您的更改的早期反馈或帮助。在这两种情况下，您都需要执行基本流程来创建 PR 或 MR。如果您使用的是 GitHub，并且不确定如何执行此操作，可以按照 此处 的说明进行操作。如果您使用的是 GitLab，并且不确定如何执行此操作，可以按照 此处 的说明进行操作。

创建 PR/MR 时，务必提供更改的上下文、您所做的更改以及人们如何测试您的更改。将链接到 PR/MR 所解决的问题是一个好习惯，并简要描述您所做的更改。此外，您的 PR/MR 应该有一个简短且描述性的标题，以使审阅者更清楚地了解其包含的内容。

如果您的更改尚未完成，您需要将 PR/MR 标记为 **草稿**，以表明您的工作尚未完成。GitHub 的说明在 此处，GitLab 的说明在 此处。您可能还想将 PR/MR 标题设置为“\[WIP]: <描述性标题>” （WIP 代表“正在进行中”）。如果您对更改有任何疑问，此草稿 PR/MR 是一个很好的提问场所，因为任何回答您的人都会了解您迄今为止所做的一切。一旦您感觉您的更改已完成/已准备好，您可以将 PR/MR 从其草稿状态转换为已准备好状态。GitHub 的说明可在 此处 找到，GitLab 的说明可在 此处 找到。

无论您的 PR/MR 是草稿还是已准备好进行审阅，请不要认为您已经完成了！您很有可能在审阅过程中花费相当多的时间，改进您的代码，直到它准备好合并到项目中。接下来，我们将讨论此审阅过程。

PR/MR 审阅过程

准备好 PR/MR 后，一个或多个人将审阅您的更改并提供反馈。如果这是您对该项目的首次贡献，那么您可能会获得很多反馈！然后，您需要进行更改以解决这些评论。为此，您只需在创建 PR 的同一分支上进行新的提交，并将更改推送到您的 origin 即可。

当审阅者建议更改您认为可运行的代码时，您可能会感到沮丧，但请记住他们的目标是提高项目的整体质量。他们提供反馈的目的是帮助您改进和提升您的编码技能！不要把反馈当作个人攻击，而应将其视为学习的机会。如果有什么原因阻止您实现请求的更改，请不要犹豫，在评论中回复，说明您为什么认为该建议可能不可行。但是，除非存在此类情况，否则请尽力整合他们提出的所有更改。这种方法将促进富有成效和协作的代码审阅过程。

另一件需要牢记的事情是，许多项目将有 **自动测试**，这些测试将在您的 PR 上运行，以确保在您更改后一切正常。如果测试似乎失败了，请尝试调查原因并查看是否可以修复它们。如果您不确定测试失败的原因，您始终可以在 PR 中添加评论，说明原因并寻求帮助。有时，测试可能会表现不一致，因此被称为“不稳定”测试。如果您确信测试失败不是由您的代码更改造成的，那么重新运行测试可能值得一试。

一旦您的 PR 上的测试通过，并且您的更改获得了审阅者（s）的批准，您的代码将由项目维护者合并到上游主分支中。恭喜！您刚刚为项目贡献了代码，并对项目和社区产生了影响！

结论

正如您希望在本文中看到的那样，有很多很棒的开源项目可以供您贡献。因此，如果您有兴趣，请选择一个并贡献！有许多贡献方式，只要项目接受贡献，您的贡献就会受到赞赏。虽然贡献（尤其是贡献代码）可能是一个复杂的过程，但它也是一种非常有意义的体验。因此，我们希望看到您在开源和 Knative 中做出贡献！

我们希望您喜欢这篇文章，并且现在对为开源做出贡献更加自信。我们也希望在 下一篇文章 中见到您！

附注：如果您有兴趣开始为开源做出贡献，请务必查看 这篇 CNCF 文章，因为它提供了很好的起点。