從零開始搞懂 GitHub 協作：開源新手必讀的名詞大全

第一次想在 GitHub 上貢獻程式碼，卻被一堆術語搞得暈頭轉向？這篇文章幫你一次搞懂所有核心概念。

作者：Ray 日期：2025 年 12 月 17 日

---

剛接觸 GitHub 的時候，我也被這些術語搞得很困惑。Fork 是什麼？PR 又是什麼？為什麼要 rebase？這篇文章把我當初希望有人告訴我的東西，全部整理出來。

先搞懂最基本的：你的程式碼住在哪裡？

Repository (Repo)

簡單說，就是你的專案資料夾，但它不只是資料夾——它記住了你每一次的修改歷史。誰改的、什麼時候改的、改了什麼，全部都有紀錄。

你可以把它想像成一個有「時光機」功能的資料夾。

Clone

把雲端的 repo 下載到你的電腦上。這樣你就能在本機開發，不用一直連網。

git clone https://github.com/username/repo-name.git

Fork

這是開源協作的第一步。

當你想貢獻別人的專案，你不能直接改人家的程式碼（想想也知道這樣會亂套）。所以你先把整個專案「複製」一份到你自己的帳號下，這個動作就叫 Fork。

Fork 出來的是你的副本，你可以隨便改，不會影響原本的專案。改好之後，再透過 Pull Request 請求合併回去。

---

版本控制的基本動作

Branch（分支）

想像你在寫一份報告，但你想試試看另一種寫法。你會怎麼做？複製一份出來改，對吧？

Branch 就是這個概念。你從主線（通常叫 main 或 master）岔出去，開一條新的線來開發新功能。這樣即使你改壞了，主線還是安全的。

git checkout -b feature/new-feature

Commit

每次你覺得「好，這個階段可以存檔了」，就做一次 commit。它會記錄：

• 你改了哪些檔案
• 什麼時候改的
• 你是誰
• 你為什麼改（commit message）

寫好 commit message 很重要。三個月後的你會感謝現在的你。

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 中引用它。

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，中文叫持續整合與部署。

簡單說，就是每次有人提交程式碼，機器會自動：

1. 跑測試，確保沒有東西壞掉
2. 檢查程式碼風格
3. 甚至自動部署到伺服器

這樣就不用人工一個一個檢查，省時又不會漏掉。

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。

git fetch upstream
git merge upstream/main

Conflict（衝突）

當兩個人改了同一段程式碼，Git 不知道該用誰的版本，這就產生了衝突。

你需要手動決定要保留哪個版本，或者合併兩者。這是協作中最讓人頭痛的部分，但也是必經之路。

Rebase

把你的 commits「搬」到另一個分支的最新點上。

跟 merge 的差別是：rebase 會讓 commit 歷史更乾淨、更線性，但操作比較複雜，搞錯了會很麻煩。

新手建議先用 merge，熟了再學 rebase。

Squash

把多個 commits 壓成一個。

有時候你開發過程中 commit 了很多次（「修 bug」「真的修好了」「這次真的」），squash 可以把它們合成一個乾淨的 commit。

---

標準協作流程：從頭到尾走一遍

1. Fork 原專案到自己帳號
2. Clone 到本機
3. 建立新 Branch
4. 修改程式碼並 Commit
5. Push 到自己的 Fork
6. 發起 Pull Request
7. 等待 Code Review
8. 根據回饋修改或討論
9. Merge 完成！

---

結語

GitHub 協作一開始確實有點門檻，術語多、流程也要習慣。但一旦搞懂這些概念，你會發現開源世界其實很友善。

不要怕犯錯，每個人都是從新手開始的。找一個 good first issue，發你的第一個 PR，開始你的開源之旅吧！