GitHub是全球最大的同性交友更正，程式碼分享平台 a.k.a.以扣交友程式設計師專屬的社群軟體。根據Wikipedia的資料指出，在上面已經有將近3200萬名開發者、超過兩億個儲存庫（當然，還會越來越多），不過因為Github用戶男性比例超過95%，所以才有了開頭被調侃成同性交友社群GayHub（真的有這網站，別搜）
這麼一個只給工程師們使用的網站，幾乎可說是跟一般市井小民完全不搭嘎的東西，為什麼我會說應該要任何人都該學呢？這就該先說到什麼是開放原始碼了。
另外，因為GH本行是讓開發者分享自己寫的東西，所以換個立場它也可以說是開發者們的…雲端硬碟？
所以…GitHub = 社群網站 + 雲端硬碟…是這樣嗎？
何謂開放原始碼
開放原始碼（Open Source），是程式設計界分享程式碼的一種方式。打個比方來說，今天我做了一款超讚的、獨一無二的餐點，想發到網路上分享給大家，一般會有兩種方式：開放原始碼與封閉原始碼（non-free software，又稱專有軟體 Proprietary software）
開放原始碼的概念，就是我將我的餐點菜譜全部分享到網路上，甭管你是餐廳大廚還是路邊的流浪漢，你是個人就可以學怎麼做這道菜。
這樣一來任何人都可以做出我的這道菜，也可以依照自己的口味改變這道菜的調味、食材，你喜歡辣一點就改辣一點、因為宗教你不吃豬肉也可以把豬肉換成雞肉。更棒的是你還可以把你調整過的口味分享給原作者（我），然後大家一起改善這道菜，讓它更好吃。
但這樣一來因為大家都知道怎麼做這道菜，自然我也沒辦法開一家餐廳賣這道菜（當然每個人做菜的口味都不一樣，這就是為什麼像Weblate、WordPress這些開源專案還是可以開公司自己賺錢去的原因）。因此開放原始碼中能營利的方法較少是一個缺點、另外寫開源軟體的作者通常是業餘，所以一方面開源專案品質參差不齊也是一個缺點。
開放原始碼
總之，開放原始碼的優點大概有以下幾個：
- 大多可以免費下載，對於個人或新創公司這真的是爽事
- 因為做的事都攤在陽光下，所以比封閉源碼的軟體安全很多
- 對開源專案知根知底，也讓任何有技術的人都可以改進開源專案、讓專案可以更加強大
但當然也是有些缺點，例如：
- 錢的問題，你都沒付錢給開發者了還期待他們幫你除錯當免費客服是不是
- 還是錢的問題，因為沒錢所以開源專案如果沒有打出名氣，就注定只能做興趣、甚至不保證會不會繼續開發
- 開源是建立在信任上的，如果真的有大佬植入病毒（例如前些日子的XZ事件），很少人會去幫開源專案Code Review，所以出事了很可怕（當然啦，要查出問題是很方便的，畢竟你東西都攤在陽光下）
所以也可以說，開源就是成也開放敗也開放啦
另外閉源的話你各位就想想Windows、Adobe全家桶、LINE什麼的應該就有感覺了，優劣應該不用另外說明吧？就是要錢跟要錢…
來認識GitHub吧
前面提過Github是個啥了，這邊要來帶大家認識幾個Github的專有名詞：
儲存庫（Repository，常簡稱repo）
在Github中，每個專案都會為自己開一個或多個儲存庫，用來存放這個專案的資料。我們會想要在Github中找的軟體，通常都是以一個個儲存庫的形式分享在GH上的。
一個儲存庫的頁面通常會長下圖這樣：
這個畫面看起來很複雜，等等我會介紹一般用戶要懂的最簡單的頁面，不用全部都懂沒關係，待會會說明不要急喔。
Git與GitHub
對英文有點敏感度的人應該可以感覺得出來，GitHub是由Git與Hub組合而成的單字。Hub在英文中是中心的意思。而Git指的是GitHub的核心，它是個版本控制軟體，就像幫檔案拍照一樣記錄下儲存庫中所有檔案的編輯紀錄，開發者也可以隨時回到某張照片中，就像哆啦A夢的時光機一樣。
網路上看到一個很不錯的比喻，Git就像玩遊戲要存檔一樣，不管有沒有寫程式應該都感覺的出來，你不可能一個人不用休息整個月就在那邊肝你的專案。這也就是為什麼要用到Git來幫你存檔，讓開發者可以今天寫一點、明天再寫一點。還可以讓一堆人一起，你寫那邊的同時我寫這邊，然後兩邊做的部分再併起來。
但Git是打指令操作的，當然、聽到指令大家是不是又要害怕了？我不會啊、感覺好恐怖、電腦壞了怎麼辦？其實不用怕，身為一個不會寫扣只會拿別人寫好的東西來用的普通市井小民，你不用管Git的存在，我會提到只是怕有人會好奇。
其他東西你各位可以不用知道沒關係，應該說前面這些東西看不懂就看不懂吧。畢竟我們學GH最大的原因就是要找好用又免費的軟體，什麼貢獻開發版本控制都跟我們沒有半點關係，我們要的就是好用的軟體而已。所以開始學習怎麼找好軟體吧！
註冊GitHub的帳戶
為什麼要註冊GitHub的帳戶呢？其實Github不像某些網站需要有帳戶才能下載，註冊這個帳戶的原因我等等說。
前往Github的官網註冊一下帳號，輸入電子郵件之類的資料就可以了。
註冊完後你會進到屬於自己的頁面，比方說我的頁面可以點這裡前往，就不截圖了。註冊完後你可以看到以下的畫面，三欄的左邊是你的儲存庫，通常不用管它，畢竟你根本不寫程式；我會有內容是因為我有在寫。中間算是類似社群軟體動態強的功能，會有一些你逛過的儲存庫什麼的。
右邊的部分是一些卡片，通常也用不太到。
左右側各可以開出一個選單，在左側的 Github Logo旁邊的漢堡按鈕開啟的是GitHub首頁上面的選單；右邊點你頭像拉出來的選單則是一些個人帳戶的選項。
如何尋找適合你的專案？
想找到一個適合自己的專案，你可以先看看網路上有沒有人分享過不錯的專案，例如Facebook、YouTube等地方都有這類專門分享Github專案的頻道。另外其實Github裡也有人專門整理每週、每日或每月推薦的專案，像以下我就找到兩個：
另外，你也可以再Github官網上用他們提供的搜尋功能搜尋，這種就要用英文搜尋了。
等等…所以具體來說到底要怎麼做？這邊就來跟大家分享兩種玩法，第一種你可以在無聊的時候閒逛用，第二種是想專找某個用途時用：
無聊時打發時間的逛法
首先，可以像剛剛說的一樣去YT或是那些推薦週報逛逛，看有沒有自己喜歡的就把它存起來去逛。也可以YT找影片，通常應該都會附連結吧？
另外，這邊要介紹的重點是GitHub內建的”探索”功能，首先點選剛剛說的，主頁面左上角那個漢堡選單的Explore按鈕
大部分的專案會像下圖呈現一張張卡片的樣子：
簡單介紹一下那幾個部分：
- 儲存庫名稱：以
作者/儲存庫的格式命名，是這個儲存庫（通常是這個專案）的名字 - 星數：如果你喜歡這個專案，可以按個讚禮貌支持一下作者。通常星數越多代表專案品質、效能之類的會越好
- 概述：作者簡單描述一下這個專案的內容，一般都是英文，看是右鍵翻譯還是自己閱讀都可以，
想練英文也可以來逛逛 - 上次提交時間：專案上一次是什麼時候更新程式碼的，用這個可以很簡單的判斷專案還有沒有維護與更新
- 語言：開發這套專案最主要的程式語言，一般沒有太大的信仰，你要用Brainfuck也可以，看不看的懂嘛…idk？
- 縮圖：通常放專案的Logo，可以欣賞一下~~
如果遇到喜歡的就可以點進去。但這樣亂逛的效率肯定很差，所以如果你有完整的目標，換個方法吧？
有目標的搜尋技巧
當然你也可以估狗，反正把Github當成一個備用的地方也可以。如果你要用官方提供的搜尋功能也可以。這邊就是會給大家幾個搜尋的小技巧：
- 盡可能使用英文：畢竟中文開發者跟英文開發者比起來還是英文開發者比較多，而且很多外文開發者為了讓國外的人也看得懂也都會用英文，國際通用語言嘛。可能等哪天台灣強大了之後GH都會是中文吧？
- 找星星多的專案：星星就跟讚一樣，如果一個專案有越多星星代表它越受大家歡迎，那品質應該也會比較高
- 找資料完整的專案：前面提到一張卡片上的六個部分，如果專案六個部分都有填完整、有給官方網站、有給範例、資料結構比較專業或貢獻者較多，都代表專案製作的更加完整
另外，搜尋時可以用一些官方提供的語法來加強搜尋準確度，例如：
| 項目 | 描述 |
|---|---|
stars:... | 刪節號可以換成如小於50個：<=50、超過1000個：>=1000等），代表星星數超過這個數量 |
user:USERAME | 指定某位作者的作品，例如user:510208代表510208（站長）做的專案 |
followers:n | 可以指定專案作者有多少人發落（類似推特的關注啦），例如followers:>=1000代表作者超過一千人關注 |
created/pushed:YYYY-MM-DD | 指定專案創建日期或上次提交的日期，vue created:<2020-01-01會檢查專案有vue的字樣在裡面、在2020年1/1之前創建的專案 |
license:LICENSE_KEYWORD | 指定專案使用的授權條款，就是你可以怎麼使用這款專案 |
archived:true/false | 過濾出儲存庫是否已經被存檔，存檔後的專案不再被開發 |
如果你真的記不起這麼多語法也不想一直開這個網站看，可以用Advanced Search來在表單裡填入條件，達成更輕鬆的搜尋。
:::tip
Github有一個隱藏的搜尋玩法，就是搜尋awesome+領域名稱，例如awesome-python、awesome-ai等等，這樣可以找到許多大佬整理好的好用專案列表
:::
找到專案了，怎麼下載？
找到專案後點進儲存庫，接著你會看到一個超級恐怖的畫面…沒有啦，熟了就還好了。
上圖是我寫的開源Discord機器人CFBot，有需求歡迎拿去用喔！
::github{repo=”510208/cfbot”}
在上圖中可以看到，專案有以下幾個部分：
- 基本操作：這個地方會告訴你儲存庫的名稱、作者，也可以在這邊叉走儲存庫、幫它按星星（標上星標）、釘選專案等簡單的操作
- 前次提交資訊：在這裡會說明最近一次提交（可以想像成拍快照或幫程式碼備份）的時間、提交ID（不用管）、提交訊息（說明這次做了什麼事）
- 關於面板：概述、星星的數量、檢視人數、貢獻者的數量等都可以在這裡看到
- 發布版本：這是專案的發布版本，有些儲存庫不會提供。這個部分提供的是作者已經確定這個東西可以穩定跑在電腦上時，作者幫你們處理好可以直接下載下來用的檔案
- 開發語言：前面有給過，這套專案用什麼程式語言開發的
- 讀我檔案（
README.md）：可以想像成專案的自我介紹、作者給它的說明書。在裡面會介紹怎麼在你電腦上跑起來、這款專案的用途等等資訊，還有些作者會把它做的跟官網一樣超花俏
所以具體來說到底要怎麼看看一個專案到底值不值得你使用它呢？你可以照以下的步驟判斷它能不能用：
值得一試的專案會有的特色
- 上次提交時間：程式不是完美的，任何程式都一定有漏洞，所以才會需要用更新來修復漏洞或添加新功能，所以提交時間離你現在時間越近越好：
- 若專案長時間未更新（如 2 年以上），可能已經過時或無人維護
- 最近幾個月仍有更新，表示開發者還在維護，可能更值得使用
- 點進Commits看看提交的頻率，越常提交通常代表作者越勤勞
- Star數量：星星的數量就是喜歡這個專案的人數，如果專案有越多星就代表越多人喜歡它，也可能代表專案的品質越高嘛
- Fork、Pull Request數量：Fork就是將專案複製一份給自己拿去用，Pull Request（PR，拉取請求）代表幫忙開發這款專案的開發者（大佬）數量
- Fork 多（如 500+），代表有開發者願意修改、延續該專案
- 如果一個專案 Fork 多但原專案不活躍，可以看看 Fork 版本是否有人維護。如果有就使用Fork版本看看
- Issue討論與回覆狀況：Issue代表問題數量，如果有不少、問題也都有人回應，代表專案是有志願者願意幫忙當免費客服（不是這樣吧…），那自然遇到什麼鳥事得到解答的機率也會比較高
- README文件完整度：
- 有以下幾個基本源見，代表開發者有心經營，專案較容易上手
- 安裝步驟，這會教你怎麼搭建專案。寫的越完整你搭完它會越安全
- 使用教學，教你怎麼使用這個軟體
- 示範範例，如果是類似框架、函式庫等軟體，就一定要有這樣的範例，不然你不是作者也不是蛔蟲，怎麼知道怎麼用啊？
- 若README只有一兩行，可能要小心評估；如果只有預設的說明文件（儲存庫名稱，下面有一個描述），那沒啥用途可以跳過了…
- 有詳細的 API 文件、使用說明，通常是值得信賴的專案
- 授權條款（LICENSE檔案）：有沒有開源專案授權條款，後面會為大家詳細比較怎麼看授權條款允許你做事的範圍，例如常見的GNU就不能拿去商用、拿它做出的軟體也都要繼續GNU
- 專案的社群活躍度：若PR長期沒人合併，表示維護者可能早就已經放生了；如果專案有活躍的社群，遇到問題時也比較容易獲得幫助，常見會用來搭社群的有Discord、LINE等軟體（最常見是DC啦，可以的話備個DC帳號也好）
總之記好這幾個重點，滿足這些重點的專案就很值得玩玩看喔！
有提供預編譯完的檔案
如果你的專案中Release有東西，代表作者有提供預先編譯好的東西，在Windows上通常是EXE、ZIP或MSI安裝檔案等、Linux上可以找deb格式安裝包、蘋果的話翻dmg檔案就對囉！
:::NOTE[預編譯檔案]
預編譯檔案指的是不需要任何開發環境，可以直接在電腦上跑起來的檔案。繼續用上面的比喻來講，原始碼就是餐點的食譜、而我料理好可以直接拿去吃的菜色就是所謂的預編譯檔案
:::
判斷該下載哪個檔案
這種時候點進Release裡最新的版本，先看看專案給的版本說明（我們會稱之為更新日誌），如果沒有說這個版本不支持你的電腦（作業系統、CPU架構等等），就可以直接下載了。如果看到很多檔案，可以找找以下幾個關鍵字：
依照檔案類型分類
| 關鍵字 | 說明 |
|---|---|
...installer...、...setup... | 有這些關鍵字代表這應該會是安裝程式，也就是下載下來後要一直下一步那種 |
...portable... | 這些關鍵字代表這個檔案是免安裝的版本，下載下來解壓可以直接使用 |
...app-image... | 這代表這是Linux或類Unix系統（Mac OS X就是其中之一）的類似安裝程式的檔案 |
依照作業系統分類
| 關鍵字 | 說明 |
|---|---|
win-x64、win-x86 | Windows 64 位元 / 32 位元版本。 |
macOS、Darwin | 適用於 macOS 的版本（Darwin 是 macOS 的內核）。 |
linux-x64、linux-arm64 | 適用於 Linux 64 位元 / ARM 版的 Linux（如樹莓派）。 |
amd64、x86_64 | 適用於 64 位元的 CPU 架構（Windows、Linux、macOS）。 |
arm、arm64 | 適用於 ARM 架構設備（如 Apple M1/M2、Raspberry Pi）。 |
依照發行方式分類
| 關鍵字 | 說明 |
|---|---|
| Stable | 穩定版本，適合一般使用者。 |
| Beta | 測試版本，可能有 bug，但包含新功能。 |
| Alpha | 早期測試版，不穩定，可能有重大 bug。 |
| Nightly | 每日自動編譯的開發版，最新但最不穩定。 |
| LTS（Long Term Support） | 長期支援版本，通常是最穩定的版本。 |
| Preview / RC（Release Candidate） | 預覽版 / 候選發布版，接近正式版但仍在測試階段。 |
依照檔案類型分類
| 副檔名 | 適用系統 & 說明 |
|---|---|
.exe | Windows 可執行檔。 |
.msi | Windows 安裝程式。 |
.dmg | macOS 安裝映像檔。 |
.pkg | macOS 安裝包（與 .dmg 類似）。 |
.app | macOS 應用程式格式。 |
.sh | Shell 腳本，通常用於 Linux/macOS。 |
.deb | Debian/Ubuntu Linux 軟體安裝包。 |
.rpm | Red Hat/Fedora Linux 軟體安裝包。 |
.tar.gz / .tar.xz / .zip / .7z | 壓縮檔案，可能包含程式碼或 Portable 版本。 |
實際舉例
假設你在 GitHub 的「Releases」頁面看到這些檔案名稱：
| 檔案名稱 | 說明 |
|---|---|
MySoftware-1.2.3-win-x64.zip | Windows 64 位元免安裝版 |
MySoftware-1.2.3-linux-arm64.tar.gz | 適用於 Raspberry Pi 或 ARM Linux |
MySoftware-1.2.3-macOS.dmg | 適用於 macOS 的安裝檔 |
MySoftware-1.2.3-win-x86-Installer.exe | Windows 32 位元安裝程式 |
下載下來的安裝我相信應該就不用說明了吧？
沒有預編譯檔案，只有原始碼
這種狀態通常就是要靠你自己編譯了。這種的話就要有一點程式語言基礎了，說明文件應該都會有所描述，照著說明的教學一步一步來，或是找其他的專案。因為各個專案都會有自己的特點，所以我也不能在一篇文章介紹完所有的方法。
這種時候就去估狗查專案名稱吧？或許會有大神幫你做好預編譯檔案喔~
開源社區的良好習慣
說句實在話，開源社區那些大佬也是人，他們也希望可以受到尊重。至於怎麼個尊重法呢？主要有以下幾種方法：
遵守開源協議，人家給你怎麼用就怎用
今天寫了個很讚的開源專案，想分享到GH上。這是每個開源貢獻者的想法，但開源軟體也是軟體、也是作者心血與肝的結晶，他們當然有權利決定軟體給誰用。這也就是出現開源協議的原因，簡而言之就是遵守別人的遊戲規則，人在屋簷下不得不低頭嘛。
在GH左邊關於面板中，有一個很重要的項目，它的圖示就像自由女神手上拿的天秤，也就是所謂的開源協議，也就是一個規定你可以怎麼使用這款專案的規則。常見的開源協議如GNU/GPL、LGPL、Apache、MIT等條款。以下我會分開介紹這些條款：
GNU/GPL（GNU General Public License）
GNU/GPL，由Richard Stallman（理查．斯特曼）於1989年發布。這裡面其實有個小故事，且聽我娓娓道來：
話說那是一個月…我不知道的日子，理查當時在AT&T工作，但他發現他為Unix系統寫的許多軟體版權都屬於AT&T的老闆，這讓他非常不爽：「老子寫好的軟體就這樣沒了？」，於是他開始大力鼓吹自由軟體的概念，並起草了GNU條款…
在GNU/Linux下方的軟體大多都是GNU條款，這個條款規定了使用者可以修改專案（廢話）、但修改完再次發布也必須透過一樣的GNU條款發布。另外這項條款規定無論是使用、匯入、修改、擴充來自GNU條款的軟體也必須改用GNU授權。而GNU授權的大綱就是不得營利（不准拿來賺錢）、不得閉源等。
簡而言之，就是「用了GNU就給我GNU開源，哪怕你只是複製一行Code也要！」，這也就是為什麼大家會說GNU是個傳染性很高的條款，因為甭管你有用到GNU軟體，就必須用同個條款。
GPL提供的Copyleft對於基於Linux的系統的成功至關重要，給予向核心貢獻的程式設計師保證他們的工作將有益於整個世界並保持自由，而不至於被不提供回饋給社群的無良軟體公司所剝削。
－ 大衛·A·惠勒
LGPL（GNU Lesser General Public License）
前面說到無論你用多少，有用就是GNU伺候。但你各位要知道我們寫程式一定會去拿別人寫好的東西來用，那如果我真的不想開GPL怎辦？看來GNU那邊也知道這樣玩百分之兩千一定會玩到出事，於是另外開了一個LGPL條款，LGPL的意思很簡單：「你有引用沒差，但改了就給我LGPL」，也就是如果你只是純粹站在巨人的肩膀上，你可以繼續閉源；但如果你改了？那就乖乖LGPL伺候啦~~
BSD（Berkeley Software Distribution License）
BSD條款來自美國加州大學柏克萊分校，他的使用相對較自由，你可以能夠自由地重製、散佈、修改、商業化。簡而言之，他跟前兩款的差別就是不管你怎麼用、愛收錢不收錢都隨便你，反正作者不收就是了，誰愛賺錢誰賺去。
一開始 BSD 條款有四條（BSD 4-clause License），其中第四條通常被稱為廣告條款，要求後面必須夾附一份貢獻者名單等等。後來移除了這個條款，所以被改稱為BSD 3-clause License。
雖然現在市面上的 BSD 條款指的是BSD 3-clause License為主，但其中的第三條：未獲事前取得書面授權，不得使用柏克萊加州大學或本軟體貢獻者之名稱，為本軟體之衍生物做任何表示支援、認可或推廣、促銷之行為。，也就是說不准拿原作者的名義來推廣你改過的軟體（就是改完了就切的一乾二淨、我不認識你你不屬於我的概念）。只是這段感覺也有點像廢話，大家用著用著也覺得這段不重要，就再次被砍成剩前兩項了：
- 對於本軟體原始碼的再散播，必須保留上述的著作權宣告、此三條件表列，以及下述的免責聲明。
- 對於本套件二進位可執行形式的再散播，必須連帶以檔案以及／或者其他附於散播包裝中的媒介方式，重製上述之著作權宣告、此三條件表列，以及下述的免責聲明。
完整授權條款
Apache條款
這是由Apache Software Foundation撰寫的條款，跟BSD比較大的差別是你要標示出改過的地方，也就是改了哪裡要說。
MIT條款
MIT條款是目前五個條款裡最自由的一個，MIT授權條款允許專有（閉源）軟體使用，只要你改過的軟體裡面包含MIT授權條款條款的副本與著作權聲明即可。
基本上如果你只想用軟體，其實這些都不重要，反正你用的了就好。只是像有些條款禁止公司企業使用、禁止被修改等等，如果有遇到可能要注意一下，給作者放點尊重吧！
看到喜歡的Code，隨手給個星星吧！
在GitHub頁面、基本操作的地方有一個Star按鈕，這個按鈕的功能相當於YT的按讚或B站的三連，是給作者的一種肯定。因此如果你喜歡專案的話，不妨考慮給作者一個星星，支持他繼續開發吧！
遇到問題記得回報，可以的話也幫忙PR
如果你遇到了問題，請看看專案頁面最上面的Issues葉面，這個地方是給使用者回報問題或建議新功能的。在回報問題時最好請各位記得幾件事：
- 完整的描述問題：比起「程式在我的電腦上噴錯誤」，告訴作者「程式在我的Windows 10電腦上跳出
TypeError...錯誤」對作者而言更方便她處理。並且請具體的描述這個問題是怎麼觸發的，例如「按了主畫面的Home就跳出來了」這樣。作者是人不是神不會通靈… - 不要一味的催促作者幫你：作者也是人，重點你沒付錢給他，他為什麼有義務要24-7當免費客服？因此不要一直催作者回答你的問題，就耐心等到他回你就好。
PR，拉取請求，這是一個可以貢獻你喜歡的專案的方式，對一般人來講可以做的有像幫忙翻譯說明文件等，這種不用寫程式的工作你們也可以試試看喔~~
結語
開放原始碼是個好的制度，可以幫助我們找到自己喜歡的軟體；對開發者而言，用賺錢方式變少換來可以讓全世界的大神跟你一起做專案，反正個人是覺得挺值得啦。