Appearance
從零開始搞懂 GitHub 協作：開源新手必讀的名詞大全
第一次想在 GitHub 上貢獻程式碼，卻被一堆術語搞得暈頭轉向？這篇文章幫你一次搞懂所有核心概念。
作者：Ray 日期：2025 年 12 月 17 日
剛接觸 GitHub 的時候，我也被這些術語搞得很困惑。Fork 是什麼？PR 又是什麼？為什麼要 rebase？這篇文章把我當初希望有人告訴我的東西，全部整理出來。
先搞懂最基本的：你的程式碼住在哪裡？
Repository (Repo)
簡單說，就是你的專案資料夾，但它不只是資料夾——它記住了你每一次的修改歷史。誰改的、什麼時候改的、改了什麼，全部都有紀錄。
你可以把它想像成一個有「時光機」功能的資料夾。
Clone
把雲端的 repo 下載到你的電腦上。這樣你就能在本機開發，不用一直連網。
bash
git clone https://github.com/username/repo-name.gitFork
這是開源協作的第一步。
當你想貢獻別人的專案，你不能直接改人家的程式碼（想想也知道這樣會亂套）。所以你先把整個專案「複製」一份到你自己的帳號下，這個動作就叫 Fork。
Fork 出來的是你的副本，你可以隨便改，不會影響原本的專案。改好之後，再透過 Pull Request 請求合併回去。
版本控制的基本動作
Branch（分支）
想像你在寫一份報告，但你想試試看另一種寫法。你會怎麼做？複製一份出來改，對吧？
Branch 就是這個概念。你從主線（通常叫 main 或 master）岔出去，開一條新的線來開發新功能。這樣即使你改壞了，主線還是安全的。
bash
git checkout -b feature/new-featureCommit
每次你覺得「好，這個階段可以存檔了」，就做一次 commit。它會記錄：
- 你改了哪些檔案
- 什麼時候改的
- 你是誰
- 你為什麼改（commit message）
寫好 commit message 很重要。三個月後的你會感謝現在的你。
bash
git commit -m "修正登入頁面的驗證邏輯"Push & Pull
- Push：把你本機的修改上傳到遠端（GitHub）
- Pull：把遠端的更新下載到本機
這兩個動作讓你的本機和雲端保持同步。
協作的核心：Pull Request
Pull Request (PR)
這是開源協作的靈魂。
當你在自己的 fork 上改好程式碼後，你會發一個「請求」給原專案，說：「嘿，我改了這些東西，你們要不要收？」
這個請求就是 Pull Request。
PR 不只是提交程式碼，它還是討論的地方。維護者可能會問你為什麼這樣改、建議你調整某些地方，你們來回討論，直到大家都滿意，才會 merge。
Merge
把一個分支的修改合併到另一個分支。當你的 PR 被接受，維護者就會把你的程式碼 merge 進主線。
恭喜，你成為這個專案的 contributor 了！
Code Review
在 merge 之前，通常會有人幫你看程式碼，這就是 Code Review。
不要害怕 review，這是學習的好機會。好的 reviewer 會告訴你為什麼要這樣改，而不只是說「這樣不行」。
Issue：專案的討論區
Issue 是什麼？
Issue 是 GitHub 內建的討論系統。你可以用它來：
- 回報 bug：「這個按鈕點了沒反應」
- 提出新功能：「希望可以支援深色模式」
- 問問題：「請問這個函數是做什麼用的？」
每個 issue 都有編號，你可以在 commit 或 PR 中引用它。
bash
git commit -m "修正登入問題 #42"這樣 GitHub 會自動把這個 commit 連結到 issue #42。
Labels
用來分類 issue 的標籤。常見的有：
| Label | 意思 |
|---|---|
bug | 程式錯誤 |
enhancement | 新功能或改進 |
documentation | 文件相關 |
good first issue | 適合新手的任務 |
help wanted | 需要協助 |
小技巧：想開始貢獻開源？搜尋 good first issue 標籤，這些通常是維護者特別挑出來給新手練手的。
自動化：讓機器幫你把關
CI/CD
全名是 Continuous Integration / Continuous Deployment，中文叫持續整合與部署。
簡單說，就是每次有人提交程式碼，機器會自動：
- 跑測試，確保沒有東西壞掉
- 檢查程式碼風格
- 甚至自動部署到伺服器
這樣就不用人工一個一個檢查，省時又不會漏掉。
GitHub Actions
GitHub 內建的自動化工具。你可以設定：
- 每次 push 就跑測試
- 每次發 PR 就檢查程式碼風格
- 每天定時執行某些任務
設定檔放在 .github/workflows/ 資料夾裡。
Linter
自動檢查程式碼風格的工具。它會告訴你：
- 縮排不對
- 變數沒用到
- 命名不符合規範
很煩，但很有用。統一的風格讓程式碼更容易維護。
專案必備的文件
一個好的開源專案，通常會有這些文件：
README.md
專案的門面。訪客第一眼看到的就是這個。
好的 README 要包含：
- 專案是做什麼的
- 怎麼安裝
- 怎麼使用
- 簡單的範例
CONTRIBUTING.md
貢獻指南。告訴想參與的人：
- 怎麼設定開發環境
- 怎麼提交 PR
- commit message 要怎麼寫
- 程式碼風格要求
LICENSE
授權條款。這個很重要！
沒有 LICENSE 的專案，別人在法律上是不能用的。常見的授權：
| 授權 | 特性 |
|---|---|
| MIT | 最寬鬆，幾乎可以做任何事 |
| Apache 2.0 | 類似 MIT，但有專利保護 |
| GPL | 衍生作品也必須開源 |
CODE_OF_CONDUCT.md
行為準則。定義社群的互動規範，讓大家知道什麼行為是被接受的、什麼不是。
進階概念：當你開始深入協作
Upstream vs Origin
這兩個詞常常讓人搞混：
- Origin：你自己的遠端 repo（通常是你 fork 的那份）
- Upstream：原始專案的 repo
當原專案更新了，你需要從 upstream 同步最新的程式碼到你的 fork。
bash
git fetch upstream
git merge upstream/mainConflict（衝突）
當兩個人改了同一段程式碼，Git 不知道該用誰的版本，這就產生了衝突。
你需要手動決定要保留哪個版本，或者合併兩者。這是協作中最讓人頭痛的部分，但也是必經之路。
Rebase
把你的 commits「搬」到另一個分支的最新點上。
跟 merge 的差別是：rebase 會讓 commit 歷史更乾淨、更線性，但操作比較複雜，搞錯了會很麻煩。
新手建議先用 merge，熟了再學 rebase。
Squash
把多個 commits 壓成一個。
有時候你開發過程中 commit 了很多次（「修 bug」「真的修好了」「這次真的」），squash 可以把它們合成一個乾淨的 commit。
標準協作流程：從頭到尾走一遍
- Fork 原專案到自己帳號
- Clone 到本機
- 建立新 Branch
- 修改程式碼並 Commit
- Push 到自己的 Fork
- 發起 Pull Request
- 等待 Code Review
- 根據回饋修改或討論
- Merge 完成！
結語
GitHub 協作一開始確實有點門檻，術語多、流程也要習慣。但一旦搞懂這些概念，你會發現開源世界其實很友善。
不要怕犯錯，每個人都是從新手開始的。找一個 good first issue，發你的第一個 PR，開始你的開源之旅吧！