Knative 開源入門指南 第一部分：開源簡介

發布於：2023-07-11 ,  修訂於：2024-01-17

Knative 開源入門指南 第一部分：開源簡介

作者：Calum Murray Red Hat 軟體工程實習生 @ Red Hat，以及 Leo Li Red Hat 軟體工程實習生 @ Red Hat

歡迎回到此入門部落格系列！在本文中，我們將提供開源簡介：什麼是開源、為什麼您應該關心，以及如何參與。

如果您已經有很多開源經驗，您可以完全跳過這篇文章，直接跳到下一篇，我們將在其中介紹如何設定您的開發環境以使用 Knative。但是，如果您是開源新手、有興趣了解更多，或是想要複習一下，我們很樂意與您討論開源的內容、原因和方式！

什麼是開源？

那麼，什麼是開源？開源背後的關鍵概念是所有原始程式碼都是公開可用的：任何人都可以讀取、變更、改進和根據自己的意願分發 [1]。

與開源軟體類似，也有自由軟體（就使用者自由而言是自由的 — 想想言論自由，而不是免費食物），它與開源的主要區別在於商業重點較少 [2]。雖然開源軟體和自由軟體之間存在重要的哲學差異，但我們不會在本文中深入探討這些差異，因為本文旨在作為更實用的指南。

有許多流行的開源軟體，您以前可能已經使用過，無論您是否知道它是開源的。例如，您的瀏覽器大部分都是開源的！如果您使用的是 Firefox，那麼您的瀏覽器（減去 DRM 程式碼）就是開源的。如果您使用的是基於 Chromium 的瀏覽器，例如 Google Chrome 或 Microsoft Edge，那麼顧名思義，您的瀏覽器是基於開源專案 Chromium，但您的瀏覽器也有專有元件。

此外，即使您個人不使用 Linux 作業系統，您可能至少聽說過這個流行的作業系統。如果您使用的是 MacOS，那麼您的作業系統與自由開源專案 FreeBSD 相關，即使 MacOS 中也內建了許多專有（非開源）軟體。因此，您的作業系統很有可能至少有一些開源程式碼在其中！

此外，既然您正在閱讀本文，您可能之前已經編程過。這可能意味著您已經使用過開源軟體，因為大多數程式語言（例如 Python、Go、Rust 和 Java）都是開源的。

開源是一種建立和分享軟體的龐大、流行且創新的方式。重要的是，這也是一個 您 可以參與的過程！

為什麼您應該參與？

既然我們知道什麼是開源軟體，以及您可能遇到過的一些開源軟體範例，那麼您為什麼應該參與開源？嗯，您可能想要參與的場景有很多種，所以讓我們討論其中一些場景以及您透過參與將獲得的好處。

一個非常常見的場景是，您是某些軟體的使用者，並且想要新增一個功能或修復困擾您的錯誤。因此，您可以透過納入該新功能或修復錯誤來為專案貢獻程式碼，或者您可以僅僅透過請求該功能或報告錯誤來為專案做出貢獻（沒錯 — 報告錯誤也是一種貢獻方式！）。另一個常見的場景是，您相信某個軟體專案，並且想要成為社群的一份子，並長期努力改進該軟體。還有一種常見情況是，您想透過以公開方式與其他有才能的人合作、建立人脈並建立您的技能來進一步發展您的職業生涯。

無論您選擇參與開源專案或社群的原因為何，許多好處都將相同。主要來說，它們將是

1. 有機會成為一個充滿活力的社群的一份子，積極合作以建立最好的軟體。

2. 有機會了解不同的技術並站在創新的最前沿。許多創新都始於開源專案。

3. 您將能夠看到您的貢獻影響一個大型專案，可能有很多使用者（例如，Knative 其中一個儲存庫的下載量約為 1000 萬次），這會讓人感到很有成就感。

話雖如此，您會讀到這篇文章，表示您可能已經想參與開源專案了（希望是 Knative！），所以讓我們深入探討您可以貢獻的不同方式。

貢獻的類型

您可以對開源專案做出許多類型的貢獻，一般來說，我們都歡迎任何形式的貢獻！請記住，不同的社群會有不同的貢獻指南，說明如何貢獻以及他們接受哪些類型的貢獻。在開始貢獻之前，請務必先與社群確認，以確保您的貢獻是正向的，而不是浪費您和他們的時間。對於特定的專案，您通常可以在存放庫中的 README.md 檔案或 CONTRIBUTING.md 檔案中找到貢獻指南，但也可能在專案網站上的其他地方。如有疑問，請詢問社群！有了這個注意事項，讓我們來討論一些常見的貢獻方式。

開啟議題（Issues）

一種很好的貢獻方式是在 GitHub/GitLab 或社群使用的任何其他平台上開啟「議題（Issues）」。例如，Knative 使用 GitHub 來追蹤議題。議題可能是一個錯誤或一個功能請求。因此，如果您在使用某些開源專案時遇到讓您困擾的錯誤，請開啟一個議題並報告它！同樣地，如果您想要某項功能，請提出一個議題要求。專案維護人員不保證會為您修復該問題，但他們通常會盡力嘗試。這是一種對專案做出貢獻的好方法，因為它可以讓社群更了解像您這樣的用戶對該專案的想法，以及您遇到的問題。

分類議題（Triage Issues）

許多開源專案會收到大量的議題，這對維護人員來說造成了大量的工作量來分類它們。但好處是，這是一個您開始參與專案的好方法，而且維護人員會非常感謝您所做的一切。

為了幫助分類議題，您可以嘗試重現錯誤報告，以確保它確實是一個錯誤，並幫助驗證針對該錯誤所做的任何修復。您也可以閱讀功能請求和提案，提出問題，並提供您對它們的喜歡/不喜歡之處的意見回饋，以及您是否認為該功能可以改進專案。

撰寫文件

貢獻開源專案的另一個絕佳方式是貢獻專案的文件。例如，如果您想為 Knative 做出貢獻，您可以嘗試修復其中一個未解決的文件議題。隨著軟體的發展，文件往往會落後。為了使專案更具可用性，人們積極貢獻以保持文件最新至關重要。這也是一個非常好的方式來了解專案在技術層面上的運作方式，因為解釋概念可以提高您對它們的理解。

參加社群活動和會議

中型和大型專案（以及一些小型專案）往往會舉辦會議和社群活動。這是一個與社群中更多人會面並分享想法的好機會。例如，在 Knative 中，工作小組會舉行每週和雙週的會議，各種貢獻者將在會中討論他們正在進行的工作，並請求對他們提出的功能提供意見回饋。我們很樂意在這些會議上見到您，它們是了解社群中正在發生的事情以及專案發展方向的好方法。若要進一步了解 Knative 中工作小組會議的舉行時間，請查看社群行事曆。

審閱 PR

一個更具技術導向的貢獻是審閱Pull Requests (PR)。在 GitLab 上，它們也稱為 Merge Requests (MR)。如果您之前沒聽過 PR，它本質上是一種讓某人請求對專案的程式碼進行一組變更的方式。因此，必須仔細審閱這些變更，以確保它們正確且運作正常。雖然如果您沒有對專案貢獻太多程式碼，可能很難完全理解程式碼中發生的所有事情，但您仍然可以在程式碼中留下評論和問題，以嘗試提高變更的整體品質。但是，如果您真的不了解程式碼，那麼驗證變更是否有效可能會更有用。如果一切正常，請留下評論說明這一點。否則，請為 PR 的作者留下評論，讓他們知道他們需要修復某些內容。

貢獻程式碼

您能做出的最具技術導向的貢獻類型可能是貢獻程式碼。這也是這篇部落格文章和整個部落格系列文章的重點，因為它涉及很多內容！但別害怕，給自己一些時間，您很快就會感到可以輕鬆地進行程式碼變更，並將它們貢獻回社群。

如何貢獻程式碼

在我們深入探討如何貢獻程式碼的細節之前，我們先花一些時間看看該流程如何運作的整體情況。貢獻的第一步是有您想要變更的內容。也許它是一個新功能，也許它是一個錯誤修復，或者也許它是其他東西。一旦您知道自己想處理什麼，最好與社群/專案維護人員確認，以確保他們希望您進行您想要做的變更。如果他們同意您提出的變更，那麼就該開始編寫程式碼了！您將在您存放庫的分支上建立一個新分支，並編寫一些程式碼。當您的程式碼正常運作時，您將開啟一個包含您的變更的 PR。在您解決這些變更並讓您的 PR 獲得審閱者的批准後，您的工作就完成了，您的程式碼將被合併！（合併是指將您的變更與程式碼庫的主要程式碼合併，以便所有人都能使用它們）。此流程可以在下圖中看到。

現在，如果您不熟悉此流程，它可能會讓人感到非常困惑。因此，為了進一步消除它的神秘感，讓我們分解每個部分並詳細討論它們。

提出變更

流程的第一步是提出變更。如果您想新增功能，這個步驟非常重要，因為社群可能實際上不想要您想要的功能，或者可能希望它以與您想像的方式不同的方式運作。在這兩種情況下，如果您在提出功能之前就開始編寫程式碼，您將會浪費大量的時間。不同的社群對於提出和接受變更的方式有不同的做法，因此請嘗試找出您感興趣的社群如何做到這一點（這通常可以在 CONTRIBUTING.md 中找到，方法是瀏覽存放庫並查看其他人正在做什麼，或是在專案網站上）。例如，在 Knative 中，我們使用 GitHub Issues 提出新功能並報告錯誤，並透過新增 triage/accepted 標籤來批准它們。此外，對於大型功能，我們要求在議題旁邊建立一個功能提案文件。但是，對於修復開發人員文件等非常小的功能，您也可以跳過此步驟，直接透過建立 PR 進行變更。

在您提出新功能或報告錯誤之前，請嘗試搜尋社群用來追蹤議題的任何平台，以查找重複項目。如果已經存在一個並已獲得批准，那太好了！您可以繼續執行流程的下一個步驟。如果它存在且尚未獲得批准，您可以隨時在議題上發表評論，表明您也遇到了這個錯誤，或者想要這個功能。最後，如果它還不存在，那麼您應該提出該功能或報告該錯誤。請嘗試在您的提案/錯誤報告中包含盡可能多的詳細資訊，這將加快流程。無論您的變更是在之前提出的還是您自己提出的，一旦獲得批准，您就可以繼續執行下一個步驟！

編寫您的變更！

一旦您的提案被接受，就該編寫您的變更了。在本節中，我們不會花太多時間討論如何編寫程式碼本身（但如果您有興趣了解如何編寫 Knative 程式碼，請務必查看本部落格系列的其餘部分！）。相反地，我們將重點關注您在編寫程式碼時應遵循的所有流程。通常，您將經歷編寫變更的流程是

1. Fork 專案並在本地複製它

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 和上游遠端的網址，請瀏覽每個存放庫，並在 GitHub 上尋找標示為「程式碼」的按鈕，或在 GitLab 上尋找標示為「複製」的按鈕。如果您按一下此按鈕，您應該會看到一個可以複製的網址。

當您擁有一個 fork，並且已將其在本機複製 (clone) 並正確設定遠端 (remotes) 後，您應該 checkout 一個新的分支 (branch) 來進行變更。如果您不確定分支是什麼以及如何建立分支，我們建議您閱讀這篇文章。我們也建議您在與主要分支 (main branch) 分開的分支上進行變更，並使您的主要分支與上游 (upstream) 的主要分支保持同步。這樣一來，您將可以輕鬆地將任何未來的變更合併到您的 fork 中，因為它們在主要分支上將共享相同的歷史記錄。要將您 fork 的主要分支與上游的主要分支同步，您可以使用 GitHub UI / GitLab UI，並將這些變更 pull 到您本機的主要分支，或者您可以執行 git checkout main && git pull upstream main (假設您沒有對您的主要分支進行任何 commit)，然後將您的主要分支 push 到您的 origin。為了輕鬆地將您本機的主要分支和您 origin 的主要分支與上游的主要分支同步，您可以使用 git sync 命令，該命令可以從這裡安裝。

現在您正在自己 fork 的分支上工作，是時候編寫您的變更了！在編寫程式碼時，需要記住一件重要的事情是專案的程式碼風格。如果所有變數都使用 camelCase，那麼您的變數名稱也應該使用 camelCase。如果有一種常見的方式來處理錯誤，那麼您應該以相同的方式處理您的錯誤。如果有很多單元測試，那麼您應該為您的變更進行單元測試（有關 Knative 中的測試更多資訊，請參閱後續的部落格文章）。如果其他人無法將您編寫的程式碼與其他程式碼區分開來，那麼您就成功地遵循了專案的風格。以下列出一些在您編寫程式碼時要記住的有用事項：

1. 變數、函式和類別的命名慣例

2. 程式碼格式/專案正在使用的自動格式化程式

3. 是否有 commit 訊息慣例？

4. 檔案命名慣例

5. 套件導入規則

6. 套件安裝政策（檢查是否有相關政策，或者是否可以安裝您需要的任何東西）

當您覺得自己取得了一些進展或變更已完成時，請務必進行 commit。有關進行 commit 的更多資訊，請閱讀這裡。Git commit 需要訊息，因此請盡量提供一些內容，因為這會讓其他人更容易理解您的變更。例如，「處理了錯誤修復」不是一個好的 commit 訊息，而「新增 try catch 區塊以防止崩潰」會更好，因為它描述了您變更的內容。

建立 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 的同一個分支上進行新的 commit，然後將變更 push 到您的 origin 即可。

當審閱者對您認為可以運作的程式碼提出變更建議時，可能會令人感到沮喪，但請記住，他們目標是提高專案的整體品質。他們提供回饋的目的是幫助您改進和提升您的程式設計技能！不要將回饋視為針對個人的行為，而是將其視為學習機會。如果有任何原因導致您無法實施要求的變更，請毫不猶豫地回覆他們的評論，說明您為何認為該建議可能不可行。但是，除非存在這種情況，否則請盡力採納他們提出的所有變更。這種方法將有助於建立一個富有成效且協作的程式碼審閱流程。

另一件需要記住的事情是，許多專案都會有自動化測試，這些測試將會在您的 PR 上執行，以確保在您的變更之後一切仍然可以正常運作。如果測試似乎失敗了，請嘗試調查原因並查看是否可以修復它們。如果您不確定為何測試會失敗，您可以隨時在您的 PR 上留言指出該點並尋求協助。有時候，測試的行為可能會不一致，因此稱為「不穩定」測試。如果您確信測試失敗不是因為您的程式碼變更所導致，那麼重新執行測試可能會是值得的。

一旦您的 PR 上的測試通過，並且您的變更已獲得審閱者的批准，您的程式碼將由專案維護者合併到上游的主要分支。恭喜！您剛剛為專案貢獻了程式碼，並對專案和社群產生了影響！

結論

正如您在本篇文章中希望看到的那樣，有很多很棒的開放原始碼專案可以做出貢獻。因此，如果您有興趣，請選擇一個並做出貢獻！有很多方式可以做出貢獻，只要專案接受貢獻，您的貢獻將會受到讚賞。雖然做出貢獻（尤其是貢獻程式碼）可能是一個複雜的過程，但這也是一個非常有意義的經驗。因此，我們希望看到您在開放原始碼和 Knative 中做出貢獻！

我們希望您喜歡這篇文章，並且現在對貢獻開放原始碼感到更自在。我們也希望在下一篇看到您！

附註：如果您有興趣開始貢獻開放原始碼，請務必查看這篇 CNCF 文章，因為它提供了一個很棒的起點。