GitHub 在升學申請中扮演什麼角色？
傳統備審 PDF 的問題在於，它只能告訴評審「你做了什麼」，但很難展現「你怎麼做的」以及「做的過程中你在想什麼」。
GitHub 能補上這個缺口。它讓評審可以直接看到你的專案結構、程式碼品質、提交歷程，以及你如何從一個粗糙的版本走到一個可以說明的成果。對技術相關科系的招生委員來說，這些細節遠比一張競賽獎狀更有參考價值。
幾種最常見的適用情境：
- 特殊選才：資訊、工程、數學、物理相關學程通常期待學生能提交作品或連結，GitHub 是最直接的入口
- 個人申請書審：在自傳或多元表現中附上 GitHub 連結，讓評審自行驗證你的實作能力
- 研究所推甄：研究計畫或履歷中附上 GitHub，讓指導教授確認你的程式基礎與研究動手能力
GitHub 不是每個申請者都需要的，但如果你的目標科系和程式、資料、工程高度相關，有一份整理得好的 GitHub 幾乎是必要的。
一份強的 GitHub 有哪些特徵？
強的 GitHub 不等於「程式碼最多的 GitHub」。評審（尤其是非技術背景的招生委員）其實很難判斷程式碼本身的品質，他們能快速判斷的是：
- README 清楚：看得出這個專案在解決什麼問題、用了什麼方式、有沒有附上操作說明或展示截圖。這是評審對一個 repo 的第一印象，也幾乎是唯一印象。
- 有部署或展示：如果是網站或工具，有一個能直接點開看的 live demo，比截圖更有說服力。Vercel、GitHub Pages、Hugging Face Spaces 都是常見選擇。
- 專案有脈絡：不只是把程式碼丟上來，而是能從提交歷程或 README 看出這個專案是如何演進的——從哪個問題出發、中間遇到什麼、現在的版本解決了什麼。
- Profile README：GitHub 支援在個人頁面放一份自我介紹。簡單說明你目前在學什麼、做過哪些方向的專案，讓訪客有個快速的整體印象。
- 置頂幾個重點專案：GitHub 允許你置頂最多六個 repo。把你認為最能代表你的方向和能力的幾個放在最上面，不要讓評審自己找。
常見的 GitHub 問題
以下幾種情況，會讓 GitHub 非但沒有加分，反而讓評審對你的印象打折：
- 大量空的或未完成的 repo：一看就是「建了資料夾但沒做什麼」。不如把還沒整理好的先設成 private，只留下能說清楚的。
- 全部都是 fork 別人的專案：Fork 本身沒問題，但如果你只有 fork 而沒有自己的作品，評審會不確定你是否真的做過什麼。
- README 只有預設模板：GitHub 自動產生的空 README 看起來很不專業。就算只有幾行，也要說明這個 repo 是做什麼的。
- 把課程作業全部推上來：課程作業不是你主動做的事，而且通常也不是能展現主動探索的東西。選擇性地保留你有額外投入的、並加上說明。
- 只有程式碼，沒有說明：評審不會去讀你的程式碼，他們只會看 README 和 demo。沒有說明的程式碼等於沒有展示。
不同方向的呈現重點
GitHub 的呈現方式，應該根據你的目標科系調整：
- 資訊 / 軟體工程：展現你能設計完整的小系統，有前後端、有資料處理、有部署。重點在「可以跑起來，而且能說明為什麼這樣設計」。
- 資料科學 / 統計：Jupyter Notebook 加上清楚的說明是常見格式（Kaggle 是練習與公開分析的好起點）。展現你能提出問題、清理資料、做出有意義的分析，並且能說清楚發現了什麼。
- 機械 / 電機 / 物理：如果有硬體專案，可以用影片或截圖說明，搭配程式碼的說明文件。重點在展現你能讓物理世界的事和程式碼連起來。
- 設計相關：GitHub 本來不是設計師主要的平台，但如果你有前端實作或互動作品，可以用 GitHub Pages 部署並附上設計說明。Behance 或個人網站可以和 GitHub 並行使用。
即使剛開始學，也可以從這裡起步
不需要等到「夠厲害」才開始整理 GitHub。評審不是在看你的技術水準，而是在看你是否有主動探索的習慣和記錄自己學習的能力。
幾個實用的起點：
- 把你做過的課程自主學習成果整理好 README 推上去
- 從一個解決生活問題的小工具開始，不需要完美，但要說清楚
- 把你讀過的某個主題整理成筆記或文件，放上 GitHub 作為「學習記錄」
- 參考你喜歡的開源專案，試著改一個小功能或修一個 bug，記錄過程
重點不是程式碼有多厲害，而是你有沒有認真對待每一個放上去的東西。一個做得認真的小專案，比十個半成品更能讓評審記住你。如果你還沒有題目，可以從如何從科系方向反推 Side Project 主題開始。GitHub 以外的展示平台選擇，可以參考個人網站與 Portfolio 怎麼做。