GitHub 是什麼？（給非工程師）

先懂 Git（跟 GitHub 只差一個字，但不一樣）

要懂 GitHub，先懂 Git。Git 是一套「版本控制工具」——它會記錄程式碼每一次的變更，讓你隨時能回到任何一個歷史版本、看到「誰、在什麼時候、改了哪一行」。

你可以把 Git 想成「無限次數的存檔點＋完整的編輯紀錄」。寫文件如果有這種功能，你就永遠不怕改壞、也永遠查得到誰動過什麼。程式碼太重要，所以工程師幾乎都用 Git 管理。

那 GitHub 是什麼

Git 是「工具」，本身跑在你電腦上。GitHub 則是「把 Git 專案放到雲端、再加上協作、討論、權限管理」的網站平台。

簡單說：Git 幫你記錄版本，GitHub 幫你把它放上網、跟別人一起協作。類似的平台還有 GitLab、Bitbucket，但 GitHub 最大、最多人用。

會遇到的幾個名詞

• repository（repo，儲存庫）：一個專案的資料夾，一個 repo 通常放一個專案的所有程式碼
• commit（提交）：一次「存檔」，把這次的修改記錄下來、附一句說明
• branch（分支）：從主線分出來的一條平行版本，讓你在不影響正式版的情況下改東西
• pull request（PR，合併請求）：「我改好了，請幫我看過再併回主線」的正式請求。程式碼審查就發生在這裡
• clone（複製）：把整個 repo 從 GitHub 抓到自己電腦上
• issue（議題）：用來記錄一個 bug 或一個需求的討論串。非工程師最常會用到的就是這個
• open source（開源）：程式碼公開，讓任何人都能看、能用、能一起改

一次協作流程長什麼樣

了解這個流程，你就看得懂工程師在說什麼、也能判斷專案有沒有基本的品質把關：

• 開分支：工程師從主線分出一條 branch 來做這次的功能，不影響正在上線的版本
• 改動並 commit：一邊改一邊存檔，每個 commit 附一句說明「這次改了什麼」
• 推上 GitHub（push）：把本機的改動同步到雲端
• 開 pull request：正式提出「請合併」，其他人可以在上面逐行留意見
• 審查（review）：同事看過、提問、要求修改。這一步是品質與資安的重要防線
• 合併（merge）：通過後併回主線，接著才會部署上線

公開與私有：最常見、也最貴的一個踩雷

建立 repo 時要選 public（公開，全世界都看得到）或 private（私有，只有你授權的人看得到）。這個選擇看起來很單純，卻是最常出事的地方。

最典型的意外是：把 API 金鑰、資料庫密碼寫在程式碼裡，然後 push 到公開的 repo。網路上有自動化程式在持續掃描新上傳的公開程式碼找金鑰，這件事可能在幾分鐘內就被抓走盜用。

更麻煩的是，把那一行刪掉、重新上傳並沒有用——Git 的本質就是保留完整歷史，舊版本裡的金鑰還在。正確的補救順序是：立刻到服務後台把那把金鑰作廢並換新，再處理歷史紀錄。詳細做法可看金鑰安全那篇。

你會在哪裡碰到 GitHub

• 想用某個免費工具，說明常寫「到 GitHub 下載」
• 跟工程師或外包合作，程式碼放在 GitHub 上一起改
• 某些 AI 開發工具會要你「授權連接你的 GitHub 專案」，它才能讀你的程式碼幫你改
• 評估一個開源工具值不值得用時，去看它的 GitHub 頁面（下面會教看什麼）

授權 AI 或第三方工具連接 GitHub 前，先檢查這四件事

越來越多 AI 工具會要求連接你的 GitHub。程式碼是公司的核心資產，授權前請先確認：

• 它要求的是唯讀還是可寫？ 只是幫你看程式碼，給唯讀就夠。可寫代表它能改動、甚至刪除你的東西
• 授權範圍是全部 repo 還是指定幾個？ 能指定就只指定必要的那幾個，不要一次開放整個帳號
• 用誰的帳號授權？ 不要用擁有組織最高權限的帳號。理想上用權限受限的專用帳號或機器人帳號
• 怎麼收回、多久檢查一次？ 事先確認取消授權的位置，並把「定期盤點已授權的第三方應用」排進例行工作

非工程師其實用得上的四件事

GitHub 不是只有工程師能用。這幾件事你自己就做得到，而且很實用：

• 評估一個開源工具值不值得用：看它「最後更新是什麼時候」（半年以上沒動要小心）、「有多少人在追蹤」、「未解決的 issue 多不多、作者有沒有在回」
• 回報問題：發現工具有 bug，可以直接開一個 issue 描述問題。多數專案歡迎清楚的問題回報
• 看更新說明（Releases）：想知道某個工具新版改了什麼，這裡通常有整理好的說明
• 確認授權條款：見下一段。這關係到你能不能商用

開源不等於「可以隨便拿來商用」

這是老闆特別該知道的一段。「開源」指的是程式碼公開，不代表沒有任何使用條件。每個開源專案都會附一個「授權條款（License）」，規定你能怎麼用。

常見的幾類，白話版：

• MIT、Apache 這類寬鬆授權：幾乎可以自由使用（含商用），通常只要求保留原作者的版權聲明。這是商用最沒有負擔的一類
• GPL 這類「傳染性」授權：如果你把它用進自己的產品並且對外發布，可能會被要求你的程式碼也要一起開源。商用前務必請人確認
• 沒有寫授權條款的專案：預設是「保留所有權利」，嚴格說來你並沒有被授權使用。看起來免費不等於可以拿
• 判斷方式：到專案首頁看有沒有 LICENSE 檔案。金額大或涉及對外產品時，這件事該由法務或律師確認，不要靠工程師或 AI 的印象

對非工程師的意義

你不用會用 GitHub 寫程式，但知道它是「程式碼的協作平台」，就能在被要求「授權連接 GitHub」時知道那是在做什麼、在跟工程師溝通時不卡名詞，也看得懂「這個工具在 GitHub 上開源」代表什麼。

如果你有外包或委外開發，還有一件事一定要確認：程式碼放在誰的 GitHub 帳號底下。放在對方帳號、你連看都看不到，是合作破裂時最常見的災難。應該在合約階段就約定好放在你公司的組織帳號，並確保你有管理權限。