GitHub

GitHub是一個聚集了數百萬開發者的網站，他們每天都在一起合作共同開發開源軟體。GitHub同時也是給軟體使用者報告問題的地方，它托管了數十億行程式碼。作為一個開發者，你應該了解GitHub中最重要的一些功能。 GitHub介紹 為什麼使用GitHub？ GitHub問題 社交式程式碼開發 關注 星標 衍生 熱門=更好 合併請求 專案管理 比較提交 Webhooks和服務 Webhooks 服務 最後一句 GitHub介紹 GitHub是一個網站，每天都有數百萬名開發者在這裡合作共同開發開源軟體。它也是軟體使用者報告問題的地方，同時也是托管數十億行程式碼的地方。 簡而言之，GitHub是一個為開發者打造的平台，並且是基於Git的。 提示：如果你對Git還不熟悉，可以查看這個Git指南。 作為一個開發者，你每天都無法避免使用GitHub，無論是為了托管你的程式碼還是使用別人的程式碼。本文將介紹GitHub的一些重要概念，以及如何使用一些提升你工作流程的功能，以及如何將其他應用程式整合到你的開發過程中。 為什麼使用GitHub？ 現在你已經知道GitHub是什麼，你可能會問你應該為什麼要使用它。 畢竟，GitHub是由一家私人公司管理的，他們從托管別人的程式碼中獲獎利潤。那你為什麼要使用GitHub，而不是類似的平台，如BitBucket或GitLab？ 除了個人喜好和技術原因外，有一個重要的原因：每個人都在使用GitHub，所以它的社群效應非常巨大。 大型程式碼庫過去已經從其他版本控制系統遷移到Git，因為Git在使用上非常方便，而GitHub在Open Source社群中一直處於很好的地位(並且付出了很多努力)。 所以今天，無論你查找任何庫，你99%的機會在GitHub上找到它。 除了Open Source程式碼外，很多開發者也會因為使用GitHub上的獨特功能而在上面託管私有庫。 GitHub問題 GitHub問題是全球最受歡迎的錯誤追蹤工具之一。 它提供了一個使庫的所有者可以組織、標記和分配給里程碑的問題的功能。 如果你在由其他人維護的項目上報告問題，它會保持開放，直到你關閉它(例如，如果你找到了問題)或項目所有者關閉它。 有時你會得到結論性答案，其他時候問題會保持開放，並且會被標記一些資訊以對其進行分類。開發者可能會根據您的反饋修復問題或改進程式碼庫。 大多數開發者並不為他們在GitHub上釋出的程式碼提供支援，所以你不能指望獲得及時的回覆。但有時候開源庫是由提供相關服務的公司發布的，這些公司可能對該程式碼提供相關服務，或提供具有更多功能的商業版本，或者有一個插件架構，它們可以作為有償的開發人員工作在開源軟體上。 社交式程式碼開發 幾年前，GitHub的標誌中包含了「社交式程式碼開發」的標語。 這表示什麼，現在是否仍然相關？當然是相關的。 關注 在GitHub上你可以關注開發者，只需要進入他們的個人資料並點擊「關注」按鈕。 你也可以關注一個庫，只需要點擊庫的「關注」按鈕。 無論哪種情況，這些活動都會顯示在你的主頁上。這裡的「關注」不像Twitter上的「關注」，在這裡你可以看到人們在GitHub上做了哪些事情。 星標 GitHub最重要的功能之一是將庫加入星標。這個動作將庫加入到你的「已加星標庫」列表中，使你可以在以後找到你之前感興趣的項目。這也是其中一種最重要的評級機制，因為一個庫獲得的星星數越多，它就越重要，並且會在搜索結果中更常出現。 重要的項目有時可能會有超過7萬的星標。 GitHub還有一個trending頁面，它會顯示在一段時間內獲得最多星標的庫，例如今天、本週或本月。 進入這些熱門列表會產生其他的社交效應，比如被其他網站推薦，因為你有更多的曝光機會。 衍生 一個項目的最後重要的社交指標是fork的次數。 這也是GitHub的關鍵功能之一，因為衍生(fork)是提交合併請求(PR)的基礎，也是一個變更建議。一個人基於你的庫進行衍生，做出一些變更，然後創建一個合併請求來請求你合併這些變更。 有時候衍生的人永遠不會請求合併任何東西，只是因為他們喜歡你的程式碼，決定在它的基礎上添加一些內容，或者解決了他們遇到的某個 bug。 衍生只是將GitHub項目的文件克隆下來，不會包含原始項目的星標和問題。 熱門=更好 總的來說，這些都是項目受歡迎程度的關鍵指標，通常還與最後提交的日期、作者在問題追蹤器中的參與度一起使用，這些都是評估你是否可以依賴一個庫或軟體的有用指標。 合併請求 在介紹**什麼是合併請求(PR)**之前，我們先來看看是如何進行的。 通常，一個人會基於你的庫進行衍生(fork)，做出一些變更，然後創建一個合併請求(PR)來請求你合併這些變更。 一個項目可能會有數百個合併請求，一般而言，一個項目越受歡迎，合併請求越多，就像React項目一樣： 一旦一個人提交了一個合併請求，使用GitHub界面很容易，該合併請求需要項目的核心維護者進行審查。 根據你的合併請求的範圍(變更數量、受到變更影響的事物數量、觸及的程式碼的複雜度)維護者可能需要多一點或少一點的時間來確保你的變更與該項目兼容。 一個項目可能會有明確的時間表，他們希望推出一些新的更改。當你在PR中說明了一個復雜的架構時，維護者可能希望保持事情簡單。 這可能意味著不是所有的合併請求都會被迅速接受，也不能保證合併請求會被接受。 就像我在上面發布的例子中，有一個在該庫中已經有一年半的合併請求。這在所有的項目中都會發生。 專案管理 除了問題跟蹤，GitHub界面還提供了其他旨在幫助專案管理的功能。 其中之一是項目(Project)。這在生態系統中非常新，並且使用非常罕見，但它是一個看板工具，有助於組織問題和待完成的工作。 維基(Wiki)旨在用於用戶文檔。到目前為止，我看到的使用Wiki最令人印象深刻的是Go Programming Language GitHub Wiki。...

回顧過去十年的JavaScript和Web的發展，真是一段驚心動魄的旅程。 儘管我書架上有一些1998年的JS書籍，但2010年時我並沒有寫很多JavaScript。當時我主要使用Mootools和jQuery插件。可能有些JS代碼是我寫的，但並沒有什麼突破性的創新。 那時的JavaScript絕對不被視為熱門語言。它的主要用途是在像GMail、Google Maps等有大量預算的項目中進行一些高級工作。 對於大多數人來說，用JavaScript編寫整個應用程序的概念當然是陌生的。 快進到2019年12月31日，JavaScript可真是太普遍了。 JavaScript無所不在。在過去的10年中，它經歷了多次更新，包括一個主要更新（ES6），如今我們寫JavaScript的方式與2010年完全不同。 異步和等待、箭頭函數、Promises、生成器、const/let、類、模板字面量等，肯定使現代JavaScript看起來和行為也非常不同。 ES模塊使大型應用程式更易於撰寫和維護。 但這不僅僅是語法和語言的新特性改變了。 我認為，這十年最大的變化之一就是構建工具的引入和廣泛使用。從Grunt到Gulp再到Webpack、Parcel和Rollup，工具的發展如此迅速，作為開發者，我們每天都有越來越大的能力。 模塊打包器為我們提供了非常高級的功能，如樹搖篩檢。了解這些技術是如何從早期發展至今真是令人驚嘆。 我們要提到Node.js嗎？從技術上講，Node在2009年春季首次推出，所以並不屬於這個十年。但可以肯定的是，Node第一年並沒有取得很大的突破，但在這十年中卻取得了巨大的成功。 現在讓我們來談談瀏覽器。2010年1月的IE版本是8，其佔有率超過50%並且Edge還不存在。Chrome作為一歲的瀏覽器佔有率僅為5%，因為1.0版本是在2008年12月發布的。你能想像嗎？如今Chrome是最受歡迎的瀏覽器，遠超其他瀏覽器。據我所知，64%的互聯網使用Chrome，而Safari佔有16%。 說到Safari，在2010年1月，iPhone 3GS已經推出（我當時沒有，我還用著Nokia。我第一部iPhone是在那一年晚些時候推出的iPhone 4）。那時JavaScript在該設備上執行速度可能不會很快。但如今移動瀏覽器可以以閃電般的速度執行JavaScript，並且JavaScript被用於使用Cordova、Ionic、React Native等令人驚嘆的框架來構建移動應用程序。 npm於2010年1月推出，它的崛起可謂驚人。起初它只是一個Node.js模塊的包管理器，如今npm也成為了前端開發的事實標準。它在去年6月份超過了一百萬個包，我敢肯定它是世界上最大的軟件目錄。 順帶一提，GitHub在2010年1月剛剛存在1年半的時間。看看它當時的樣子真是有趣。 在這十年中，許多驚人的項目應運而生。我可以提到Ember.js、CoffeeScript、Angular、React，只舉幾個例子。 我有幸參與並加入了許多不同的社區，而JavaScript和整個生態系統之所以在這十年中發展如此迅速，是因為工作在其中的人們。 憑著熱情、勤奮、承諾和慷慨精神，開源社區以及成百上千的充滿企圖心的公司，使JavaScript這個開發世界的一角成為今天的模樣。 回顧過去，看到我們走了多遠真是令人愉悅。 我真的無法想像這個未來十年會帶給我們什麼。

最近，我在 Netlify 上創建了一個新的網站，希望將其中一部分公開在 GitHub 上，以便任何人都可以提交錯別字等問題的拉取請求。 我在 Hugo 倉庫中有一個名為 content 的文件夾，我想公開的部分是一個名為 handbook 的文件夾。 因此，我為此創建了一個新的倉庫，名為 handbook。 我刪除了父倉庫中的 content/handbook 文件夾（如果您從頭開始創建，則不需要此步驟，但我希望移動現有內容）： rm -rf content/handbook 然後我提交了更改，然後添加了子模組： git submodule add https://github.com/flaviocopes/handbook 我在 Netlify 上部署了網站，它自動捕獲了子模組。 但在本地上遇到了一個問題，因為並不是像子模組存儲庫文件夾上有著符號鏈接這樣。 我刪除了 content/handbook 文件夾，並從子模組的本地存儲庫添加了一個符號鏈接： ln -s ../../../dev/handbook/ 然後，我告訴 Git 停止跟踪 content/handbook 文件夾，使用以下命令： git update-index --skip-worktree content/handbook （要恢復跟踪，請使用 --no-skip-worktree） 這樣，我既有子模組，也在本地上有指向子模組的符號鏈接，兩者兼得。

或者在GitLab或其他公共源代碼管理平台上。現在該怎麼辦？ 我偶然發現了一個網站，該網站不斷掃描GitHub、GitLab和BitBucket，這是三個最常用的公開源代碼主機地方，並展示了提交的SSH密碼、常用服務的API金鑰、數據庫等等。 這讓人很害怕，對吧？ 如果這從未發生過，請舉手。我們都會犯錯。當這種情況發生時，唯一的辦法就是迅速使公開的密碼或API金鑰失效。 對於新手來說，在Git中，你不能只是回滾提交，因為它仍然會保留在存儲庫的歷史記錄中。 你的聲譽、項目的聲譽、用戶的安全都面臨風險。 在解決緊急情況後，問題是：如何避免這個問題？答案是什麼？有什麼解決方案可以幫助我們避免將密鑰提交到公開可用的Git存儲庫中？ 答案是：工作流程和工具。 首先，永遠不要將API金鑰或密碼添加到源代碼中。它們可能悄悄地藏在那裡。相反，始終將它們添加到項目根文件夾中的.env文件中，並將.env添加到.gitignore文件中，這樣就不會被提交。使用類似dotenv的工具來訪問它們。 使用git-secrets工具，它將幫助你避免將密鑰提交到Git中。 在macOS上，你可以使用Homebrew進行安裝： brew install git-secrets 然後進入要在其上啟用它的存儲庫中，運行： git secrets --install 以安裝Git pre-commit hook。這將確保在Git提交到存儲庫之前運行該工具。 如果你使用Amazon Web Services (AWS)，運行以下命令以添加該服務的識別模式集： git secrets --register-aws 你可以立即使用以下命令掃描問題： git secrets --scan 理想情況下，該工具不應該打印任何內容。但如果有問題，它會提供詳細的信息。

我的網站是基於Hugo的，它是一個靜態網站生成器。 雖然有像Forestry等工具可以在其之上使用視覺化的內容管理系統，但我並不是很喜歡它們，而且我組織內容的方式並不適合這些工具。一個簡單的例子就是圖像。它們通常希望您將所有圖像存儲在一個文件夾中，而我則為每篇文章創建一個文件夾，並將文件放在其中。 總之，我在我的Mac上使用VS Code編輯Markdown，然後將更改推送到GitHub。 在iPad上，我使用GitHub的一個很棒的功能，直接在瀏覽器中編輯文件，本質上是在雲端運行的VS Code。 這非常酷，也許有一天我會完全使用這個功能，而不再使用Mac上的VS Code。 下面是它的工作原理。 如果你有一個名為https://github.com/userName/repositoryName的存儲庫，將瀏覽器指向https://github.dev/userName/repositoryName 換句話說，只需將.com改為.dev，你就可以在Safari的VS Code視圖中看到你的存儲庫。 從這裡，你基本上可以像在VS Code中一樣工作，但在瀏覽器中。唯一仍然不完全正常工作的是搜索，它需要在本地存儲中索引文件，但在Safari中效果並不完美。 我還需要注意不要嘗試使用cmd-w來關閉VS Code標籤，因為那樣會關閉Safari標籤。 此外，我在處理圖像時遇到了一個問題，例如如果我在iPad上進行截圖，它們的大小相當大，並且解析度很高（超過1MB？），而我通常將圖像轉換為JPG格式，因為這更高效。但這是我之後可以在Mac上處理的問題。我可以有一種處理圖像的系統在雲端執行，但我到目前為止還沒有需要它。 除此之外，完成更改後，我將它們推送到GitHub。

這是一篇介紹如何在Linux上管理Node進程並透過GitHub Webhooks自動重啟它們的技術文章。 pm2是一個非常有用的Linux進程管理工具。 我在幾個項目中使用過它，現在我想告訴你如何使用它！ 特別是我將使用它在DigitalOcean VPS上運行一個Node.js應用程式，並設置當我們將應用程式的更新推送到GitHub存儲庫時，pm2將會被觸發，從GitHub更新應用程式並重啟它。 聽起來很酷吧？那我們開始吧！ 首先，在DigitalOcean上註冊並按照我的教程创建一個VPS。 重要提示：在DigitalOcean上使用NodeJS映象，它已經設置了pm2和node，而且除了root用戶外還有一個nodejs用戶。 當你的VPS運行起來之後，我們可以開始了。 確保你使用nodejs用戶進行ssh登錄。當以root身份登录時，只需運行su nodejs以使用該用戶。 你在VPS上運行的示例Node.js應用程式位於/var/www/html/文件夾中，它由hello.js文件組成。 應用程式的部署/運行已經通過pm2程序進行管理，它是一個守護進程管理器。 你可以使用pm2 list命令來查看現在正在運行的所有應用程序： 如果你對應用程式做任何更改，這些更改將在重新啟動應用程式之前不會生效： pm2 restart hello 你可以停止正在運行的應用程式： pm2 stop hello 如果你嘗試重新加載頁面，這將在瀏覽器中產生一個錯誤： 你可以運行： pm2 start hello 將應用程式重新啟動。 pm2的好處是，當系統重新啟動時，它會自動重新運行應用程序。 現在你已經看到了內置的Hello World的運行方式，讓我們部署另一個應用程式。 讓我們停止當前的示例應用程式： pm2 stop hello 並在/var/www/html中創建一個名為test的文件夾： mkdir test 進入該文件夾： cd test 運行以下命令： npm init -y 然後安裝Express： npm install express 現在運行nano app.js並添加以下代碼： const express = require("express") const app = express() app.get("/", (req, res) => res.send("Hello World!")) app.listen(3000, () => console....

我正在設置一個新的編輯器，並嘗試進行GitHub的推送工作流程。 我提交了我的更改，點擊“Push”按鈕，然後出現一個對話框要求輸入GitHub帳號和密碼。 在GitHub上，我已經設置了雙重認證，因此不能只使用這些憑證直接登錄。 我需要做的是創建一個與應用程序綁定的個人訪問令牌，並具有所需權限。 所以，我進入GitHub設置中，找到開發者設置： 點擊個人訪問令牌： 現在添加一個名稱，以便您記住此令牌的用途，將到期時間設置為“不過期”，並啟用repo範圍。這是您唯一需要的範圍： 保存後，您將能夠看到這個令牌： 現在將此令牌作為對話框窗口中的密碼輸入。 完成！

我曾經有這樣的需求：有兩個GitHub存儲庫需要包含完全相同的內容。無論何時我推送更改，這些更改都必須同時發送到這兩個存儲庫，而不需要額外的工作。 以下是我所做的： 我已經有一個工作中的存儲庫，其中包含一些代碼，並在Git中設置為“origin”遠程。 我在GitHub上創建了一個新的空存儲庫，並將其設置為“origin”遠程的另一個URL： git remote set-url --add --push origin [[email protected]](/cdn-cgi/l/email-protection):flaviocopes/original.git git remote set-url --add --push origin [[email protected]](/cdn-cgi/l/email-protection):flaviocopes/clone.git 完成！現在，只需執行“git push”命令，即可將更改推送到兩個存儲庫中。

設定 GitHub 認證，以便您可以在 VS Code 或命令列中使用它。 我通常使用 GitHub Desktop 應用程式與我的 GitHub 帳戶互動，這是我所有程式碼和網站的 Git 儲存庫。 但有時候您需要使用 git 命令列，或者使用 VS Code 中的 Git 整合功能。 如果沒有進行以下步驟，您可能會遇到認證問題。 讓我們設定它。 我假設您已經安裝了 Homebrew。 請在命令列中執行以下命令： brew install gh 然後使用 gh 工具： gh auth login 之後回答幾個問題。 選擇 HTTPS： 選擇 Y： 接著登入瀏覽器： 點擊 Authorize GitHub： 完成： 回到您的終端機或 VS Code，一切將按預期運作。

如何在GitHub上編輯項目並創建PR呢？ 關於這個主題有很多教程，但許多教程過於複雜，它們假設你必須為項目做出代碼貢獻，所以還有一些git設置。 如果你只需要編輯一個文件，比如修正項目的README中的拼寫錯誤呢？ 你不需要知道如何編程或如何使用Git來完成這個操作。但是，一旦你開始進行Pull Request，你就可以進行更多事情並與其他人協作項目！也許這會激勵你在以後貢獻代碼。 假設你已經有一個（免費）GitHub帳號。如果沒有，請訪問github.com生成一個。 讓我向你展示整個流程。 我找到了一篇可能有拼寫錯誤的文章，該文章存在於這個頁面：https://web.dev/prefers-color-scheme/ 我知道該網站是托管在GitHub上的，具體該文章位於這裡：https://github.com/GoogleChrome/web.dev/tree/master/src/site/content/en/blog/prefers-color-scheme 我直接在GitHub上打開index.md文件https://github.com/GoogleChrome/web.dev/blob/master/src/site/content/en/blog/prefers-color-scheme/index.md，然後按文件工具欄中的鉛筆圖標。將鼠標懸停在圖標上會顯示“Fork this project and edit the file”。 這將打開一個編輯器界面，顯示以下信息： 你正在編輯一個你沒有寫權限的項目中的文件。將提交對這個文件的更改，將它寫入你的fork flaviocopes/web.dev 的一個新分支中，然後你可以發送一個pull request。 我在文件中添加了那個句號，然後在底部的表單中解釋了我所做的更改： 我點擊了“Propose File Change”按鈕，然後顯示了一個比較視圖： 在這裡，我可以查看我所做的更改，確保一切都正常，最後我可以點擊“Create Pull Request”按鈕。目前這些更改已經發生在你fork的項目上，當你點擊鉛筆圖標時，GitHub會自動創建你的fork。 在這個視圖的頂部，你可以看到我正在將一個PR提交到GoogleChrome/web.dev項目，從我的fork flaviocopes/web.dev的分支patch-2到他們的master分支。 點擊“Create Pull Request”按鈕會顯示另一個表單，在這裡我可以為Pull Request撰寫詳細的描述。 Pull Requests可以包含多個不同的更改，理論上你可以在同一個PR中編輯許多文件，這就是為什麼你可以添加摘要。 這個倉庫有一個用於PR文本的模板，以幫助團隊管理它。我們的PR非常簡單，所以我移除了模板，只是將之前提交消息中的內容粘貼了過來。 右邊的提示看到了嗎？他們告訴我這個項目有一個CONTRIBUTING.md文件，其中解釋了如何參與貢獻和遵守的準則。非常酷。 看起來我們需要簽署一個CLA（貢獻者授權協議）來完成我們的PR。我過去已經簽署了Google的CLA，所以對我來說這一步很清楚，但你可能需要處理這個。大多數項目實際上不需要它。 我點擊“Create pull request”，PR現在已經提交！ 現在由項目維護者來接受，你只需要等待一封郵件告訴你它是否被合併，或者其他人是否有評論。 […過了幾個小時…] 我收到了一封郵件，該PR被拒絕了，因為那個句號實際上是在正確的位置上！（我不知道） 但無論如何，這是我想要添加的一個事情：如果你提交的PR不被接受，不要生氣或沮喪。項目的維護者可能花了好幾個月或幾年的時間，他們對於項目的了解比你更多。 此外，特別是對於代碼而言，觀點可能非常不同，你認為很好的PR可能不被歡迎。 最好在進行實質性PR之前先詢問，看看項目是否真的需要這樣的改變。 但這是另一個話題。