GitHub 是什麼？Git、PR、CI、E2E 這些名詞一次搞懂

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

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

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

那 GitHub 是什麼

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

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

程式碼會經過的四個地方

最容易卡住的地方，是搞不懂為什麼存個檔要打三、四個指令。原因是 Git 把「改東西」到「傳上雲端」切成了幾段，每一段都是一個可以反悔的關卡。

• 工作區（working directory）：你電腦上正在編輯的那些檔案，跟平常用 Word 改文件沒兩樣
• 暫存區（staging area）：一個「待送清單」。你今天改了五個檔案，但只想送其中兩個，就用 git add 把那兩個放進來
• 本機版本庫（local repository）：git commit 之後，這次的改動變成一個正式的存檔點，存在你自己的電腦裡。這時候還沒有人看得到
• 遠端（remote）：雲端上的那一份，也就是 GitHub。git push 才是真正上傳。多數專案的遠端只有一個，預設名字叫 origin
• git pull：把別人推上去的更新拉到你電腦。開始工作前先 pull 一次，可以少很多麻煩
• git clone：第一次把整個專案從 GitHub 整包抓下來，之後就不用再 clone 了

名詞一次看完

跟工程師開會時最常出現的就是這些字。先掃一遍有印象就好，後面幾張圖會把它們串起來：

• repository（repo，儲存庫）：一個專案的資料夾，一個 repo 通常放一個專案的所有程式碼
• commit（提交）：一次存檔，把這次的修改記錄下來、附一句說明
• branch（分支）：從主線分出來的一條平行版本，讓你在不影響正式版的情況下改東西
• main（主線）：預設分支的名字，代表「目前正式的版本」。比較舊的專案會叫 master，是同一個東西
• pull request（PR，合併請求）：「我改好了，請幫我看過再併回主線」的正式請求。程式碼審查就發生在這裡
• merge（合併）：審查通過後，把分支的改動併回主線
• conflict（衝突）：兩個人改到同一行，Git 不敢替你決定留哪個，停下來等人處理
• fork（分叉）：把別人的 repo 複製一份到你自己的帳號底下
• issue（議題）：用來記錄一個 bug 或一個需求的討論串。非工程師最常會用到的就是這個
• README：repo 首頁那份說明文件，講這個專案是什麼、怎麼安裝、怎麼用。評估一個工具先看它
• .gitignore：一份「這些檔案不要上傳」的清單。密碼檔、暫存檔都該寫進去
• release / tag：把某個版本標記起來並附上更新說明，例如 v1.2.0。想知道新版改了什麼就看這裡
• open source（開源）：程式碼公開，讓任何人都能看、能用、能一起改

做一個新功能，流程長什麼樣

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

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

兩個人改到同一行，會發生什麼事

「衝突（conflict）」聽起來很可怕，其實是 Git 最貼心的設計之一。它不是錯誤訊息，是 Git 在說「這一行兩個人都改了，我不敢替你決定」。

• 改到不同檔案，Git 自己併好，你不會知道有這回事
• 改到同一個檔案的不同地方，Git 也自己併好
• 只有改到同一行才會停下來，把兩個版本並排給你看，由你決定留哪個或兩個都要
• 解法就是打開那個檔案、把要的留下來、刪掉標記，再 commit 一次
• 開始改之前先 git pull，可以避開大部分的衝突。衝突通常是因為手上的版本太舊

CI 與 CD 是什麼（每次交程式碼，機器自動做的事）

這兩個縮寫幾乎一定會在會議裡聽到。拆開來看其實很單純：

CI（Continuous Integration，持續整合）：每次有人交出改動，機器就自動把整包程式碼檢查一遍。跑測試、檢查格式、試著建置一次、掃有沒有把密碼寫進程式碼。任何一項沒過，PR 上就出現紅色叉叉，合併按鈕按不下去。

CD（Continuous Delivery／Deployment，持續交付／部署）：檢查通過、合併之後，機器自動把新版本送上正式站，不必有人手動上傳。

• GitHub Actions：GitHub 內建、負責跑這些自動化的服務。要檢查什麼、怎麼部署，都寫在專案裡的一份設定檔
• 為什麼值得在意：有 CI 的專案，「改壞了才發現」的機率低很多。問外包「你們有沒有跑 CI」是一個很快的品質判斷
• 紅燈綠燈：PR 頁面上綠色勾勾代表全過、紅色叉叉代表有東西壞了。不用懂細節，看顏色就知道能不能併
• 它也會花錢：公開專案用標準規格的機器免費，私有專案有免費額度（GitHub Free 方案每月 2,000 分鐘、每月初歸零），超過要付費。額度是整個帳號共用，不是每個專案各算一份。各方案的額度與超額價格見 GitHub 要錢嗎？

CI 到底在跑什麼測試（單元、整合、E2E、煙霧）

上一段說 CI 會「跑測試」，但測試分好幾種，各管各的事。開會時最常聽到的是這幾個：

• 單元測試（unit test）：只測一個小零件。例如「輸入 100 元、打八折，會不會算出 80」。跑一次不到一秒，所以可以寫很多、每次改動都跑
• 整合測試（integration test）：把幾個零件接起來測。例如「下單之後，庫存有沒有真的減一、訂單有沒有真的寫進資料庫」
• E2E 測試（end-to-end，端對端測試）：開一個真的瀏覽器，從頭到尾走一遍使用者會走的路：打開網站、登入、加進購物車、結帳。最接近真實情況，但也最慢，而且畫面一改就容易壞掉，需要花力氣維護
• 煙霧測試（smoke test）：名字來自硬體業，通電之後看會不會冒煙。上線後馬上跑一份極短的清單，只確認最重要的那幾件事還活著：首頁開得起來、登入進得去、能下一筆單。通常一分鐘內跑完
• 迴歸測試（regression test）：確認「以前修好的 bug 沒有又跑回來」。實務上就是把每次出過事的情境留成測試，之後每次都跑一遍

測試全過，不代表使用者看到的東西是對的

這是最常見的一個誤會，也值得寫進你的驗收標準。單元測試保證的是「每個零件自己算對了」，它不會知道畫面長什麼樣。

版面跑掉、按鈕被蓋住點不到、手機上少了一個欄位、頁尾寬度跟內文對不齊，這些單元測試全部抓不到，但使用者一打開就看到。所以驗收時除了問「測試有沒有過」，還要真的打開來看一眼，或者要求有 E2E 測試涵蓋主要流程。

反過來說也不必走極端。E2E 寫太多會慢到沒人想跑、改個按鈕位置就一堆紅燈。實務上多數團隊的做法是：單元測試寫多一點，E2E 只蓋最重要的幾條路（能不能登入、能不能下單、能不能付款），上線後再跑一次煙霧測試。

fork 跟 clone 差在哪

這兩個很容易搞混，但用途完全不同。

clone 是「把專案抓到我電腦上」，雲端那一份還是原本那個 repo，你改完可以直接推回去（前提是你有權限）。同一個團隊內部協作用的是 clone。

fork 是「把整個 repo 複製一份到我自己的 GitHub 帳號底下」，變成你的東西。你在自己那份上面隨便改都不會影響原作者。改好之後如果想回饋給原專案，再從你的 fork 開一個 PR 過去，由原作者決定收不收。

所以：團隊同事用 clone，對外部開源專案貢獻用 fork。

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

建立 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 這類「傳染性」授權：如果你把它用進自己的產品並且對外發布，可能會被要求你的程式碼也要一起開源。商用前務必請人確認
• 沒有寫授權條款的專案：GitHub 自己維運的授權說明網站講得很直白——作品預設就是「專屬著作權」，別人複製、散布或修改都可能面臨法律風險。看得到原始碼不等於可以拿來用
• 判斷方式：到專案首頁看有沒有 LICENSE 檔案。金額大或涉及對外產品時，這件事該由法務或律師確認，不要靠工程師或 AI 的印象

對非工程師的意義

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

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