🌈 今天不用硬背，先玩懂 Git

把 Git 變成一座好玩的「版本遊樂園」

這版用更活潑的配色、更像遊樂園的學習動線：先看圖、再玩模擬器、接著跑多情境實例，最後用測驗確認。每個命令都用生活比喻、圖解與可操作範例帶你走。

🎮 先玩模擬🧠 再看心智圖🌳 樹狀學習路線🎬 情境闖關🎯 15 題測驗
✨

怎麼開始最不痛苦？

不要從第 1 章硬讀到第 14 章。先玩互動，再回來補觀念，學起來會輕很多。

🎮

先玩模擬器

看檔案如何從工作區移動到遠端。

 🎬

再跑情境

用真實工作狀況理解指令順序。

 🎯

最後測驗

抽 15 題確認自己是否真的懂。

✅ 2026-06-12 官方查核與深化確認

本區只補內容，不改上一版 UI。已依 Git 官方、GitHub Docs / Changelog、GitLab Docs、SemVer 官方規格，以及上傳教材的 14 章架構，重新確認每個不可忽略的知識點。

🟢 保留且深化

Git 三區/四區、blob/tree/commit、branch/HEAD、merge/rebase/conflict、remote/fetch/pull/push、PR/MR、SSH、Tag/SemVer、Hooks、GitLab、maintenance、stash/worktree、submodule/cherry-pick/patch。

🟡 狀態標註

git switch / git restore 已作為新手優先命令；git checkout 仍保留且常見，不寫成已退役。git history、git repo、git last-modified 等仍標成 experimental。

🔴 已修正過時說法

不寫死 GitLab 價格、配額與 CI 分鐘數；GitLab 自建升級補 PostgreSQL 17、Ubuntu 20.04 / SUSE / Redis 6 / Mattermost / Helm chart 與 Envoy Gateway 變更。

版本查核結果：截至 2026-06-12，Git 官方首頁與 Git for Windows 官方安裝頁仍列 2.54.0 為最新穩定版本；GitLab 19.0 已在 2026-05-21 發布，且 19.0.2 在 2026-06-10 發布安全修補；GitHub required reviewer rule 已在 2026-02-17 GA。

🎡 快樂學習遊樂園：先玩、再懂、再上手

今天的學習順序

不要先背命令。先把 Git 想成「版本城市」：你在本機改稿，把要保存的內容放入送審籃，歸檔成版本，再同步到雲端。

① 看圖
② 按模擬器
③ 跑情境
④ 測驗

官方查核後的安全學習原則

本版把 stable、experimental、planned、deprecated 分清楚；不把 Git 3.0 預告當成已發布；不把 checkout 誤寫成已退役；不寫死 GitLab 價格與配額。

✅ 官方查核🌈 活潑 UI🎮 多互動🧪 新手白話

🧪 多情境互動範例實驗室

不只房仲。點一個情境，直接看「應該用哪些 Git 命令、為什麼、哪裡危險」。

請點上方任一情境，這裡會產生流程。

🧠 一張圖先看懂 Git / GitHub / GitLab

Git 是你電腦裡的版本機器；GitHub / GitLab 是把版本放到雲端、讓團隊審查與自動化的平台。

Git
版本控制
🧱 三區模型add / commit / push
🌿 分支與 HEADswitch / merge / rebase
☁️ 遠端協作fetch / pull / push
🔍 PR / MRreview / CI / rules
🏷️ 版本發布tag / SemVer / release
🛡️ 治理安全hooks / rulesets / GitLab
點心智圖節點：會在這裡顯示白話解釋。

🌳 四階段學習樹

Git / GitHub / GitLab 學習樹
├─ 第一階段：本機基礎
│ ├─ 第 1 章：安裝與角色分辨
│ ├─ 第 2 章：三區模型與物件
│ ├─ 第 3 章：分支與 HEAD
│ └─ 第 4 章：merge / rebase / conflict
├─ 第二階段：遠端協作
│ ├─ 第 5 章：remote / clone / push
│ ├─ 第 6 章：fetch / pull / push
│ ├─ 第 7 章：PR / MR / Rulesets
│ └─ 第 8 章：SSH Key
├─ 第三階段：發布治理
│ ├─ 第 9 章：Tag / SemVer / Release
│ ├─ 第 10 章：Hooks
│ └─ 第 11 章：GitLab / Code Owners
└─ 第四階段：進階救援
├─ 第 12 章：大型 repo 維護
├─ 第 13 章：最佳實踐與危險命令
└─ 第 14 章：submodule / cherry-pick / patch

🎮 Git 四區互動模擬器

把 Git 想成「改稿 → 放入送審籃 → 歸檔成版本 → 上傳雲端」。先玩這個，再看命令會簡單很多。

📝 工作區

正在編輯的檔案

📥 索引區 Stage

準備提交的清單

📦 本地倉庫

commit 歷史

☁️ 遠端倉庫

GitHub / GitLab

請先按「新增/修改檔案」。

🎬 情境闖關：你現在遇到哪一種工作？

🧑‍💻 新專案上傳
👥 團隊協作
🔥 衝突救火
🏷️ 版本發布
🏢 GitLab 自建
選一個情境：下面會產生「白話流程 + 命令 + 危險提醒」。

🧩 拖拉練習：把命令放到正確位置

把左邊命令拖到右邊分類。這比硬背更有效，因為你會知道命令到底影響哪裡。

📚 14 章圖解互動區

每章先看圖，再看白話，再看實例。勾選「我懂了」會記錄進度。

🧰
第 01 章

Git 介紹與安裝

Git 是本機版本控制；GitHub / GitLab 是協作平台。不要把它們混在一起。

🖥️ Git

像你電腦裡的「版本保險箱」。沒有網路也可以 commit、branch、merge。

☁️ GitHub / GitLab

像把保險箱副本放到雲端，讓團隊看、審查、自動測試與部署。

你的電腦Git 本地 repoGitHubPR / ActionsGitLabMR / CI/CD團隊協作審查 / 權限 / 自動化
🏠
房仲例

做物件網站改版，用 Git 記錄每次改了哪張圖、哪個表單。

🍰
餐飲例

菜單網站每次調價格都 commit，錯了可以回復。

📚
教學例

課程講義版本用 Git 管理，避免「最終版_final2」混亂。

🌈 深化：安裝不是重點，先分清楚角色

Git

在你電腦裡保存版本。即使沒網路，也能 commit、branch、merge。

GitHub

偏向雲端協作、PR、Actions、Rulesets、Pages、Codespaces。

GitLab

Repo、MR、CI/CD、群組權限、自建部署與 DevSecOps 平台治理。

安裝→設定 user→設定 main→確認 git --version
git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
git config --list --show-origin
截至 2026-06-12 官方查核：Git / Git for Windows 2.54.0 是穩定主線；安裝前仍要回官方頁面再次確認。
Windows 新手建議 Git for Windows 官方安裝包，編輯器選 VS Code 或 Nano，避免被 Vim 卡住。
🧱
第 02 章

三區模型與 Git 物件

Git 最核心就是三個地方：工作區、索引區、本地倉庫，再加上遠端倉庫。

📝 修改檔案
Working Dir
📥 git add
Stage
📦 git commit
Local repo
☁️ git push
Remote
👥 團隊看得到
GitHub/GitLab

🌳 .git 內部樹狀圖

.git/
├─ HEAD：目前所在位置
├─ config：本地設定
├─ objects/：blob / tree / commit 物件
├─ refs/heads/：分支指標
├─ refs/tags/：標籤指標
└─ index：暫存區索引
blob

檔案內容本身，不記檔名。

tree

資料夾結構與檔名對應。

commit

一次版本節點：作者、時間、tree、parent、訊息。

🧱 深化：git add 到底做了什麼？

工作區

你實際正在改的檔案。Git 只看到「有變」，還不知道你要不要提交。

Stage

下一次 commit 的購物車。git add -p 可只挑部分修改。

.git/objects

Git 將內容壓縮成 blob/tree/commit。這就是版本可追溯的核心。

git diff                 # 工作區 vs Stage
git add -p               # 互動挑選要放進 commit 的片段
git diff --staged        # Stage vs 上一版 commit
git commit -m "feat: add landing page"
git cat-file -p HEAD     # 進階：看 commit 物件內容
不要不看 diff 就 git add .，最常見事故是把 .env、token、debug 檔一起送出去。
SHA-256 repo 雖已不是實驗性，但一般協作仍應先確認 GitHub/GitLab 與團隊工具鏈支援。
🌿
第 03 章

分支與 HEAD

Branch 是「貼在 commit 上、會移動的便利貼」；HEAD 是「我現在站在哪裡」。

ABCDEmainfeature / HEAD
git switch -c feature-login
# 傳統但仍常見：git checkout -b feature-login
Detached HEAD 像「站在歷史照片上修圖」：如果沒開新分支保存，之後可能找不到。
git switch --detach HEAD~3
git switch -c save-my-work
git branch -d feature-login      # 安全刪除
git branch -D feature-login      # 強制刪除
git push origin --delete feature # 刪遠端分支

🌿 深化：分支像便利貼，不是複製整份資料夾

main

穩定主線，通常部署或發布從這裡來。

feature/*

功能分支，完成後走 PR/MR 合入主線。

Detached HEAD

你站在某個 commit 上，不在分支上。要保存就立刻開新分支。

git switch main
git switch -c feature/search-filter
git branch -vv
git switch --detach HEAD~3
# 若想保存 detached 狀態的修改：
git switch -c save-old-version
switch / restore 新手優先；checkout 仍保留且常見，所以要能讀懂舊教學。
刪分支只刪 ref，不一定立刻刪掉 commit；但無 ref 的 commit 之後可能被 GC 回收。
🔀
第 04 章

Merge / Rebase / Conflict

Merge 是把兩條路合起來；Rebase 是把你的路搬到新地基上；Conflict 是兩邊改到同一塊。

Rebase 黃金法則：已 push 到遠端、且別人可能基於它工作的 commit，不要亂 rebase。若真的要強推，優先用 --force-with-lease。

🔀 深化：Merge 與 Rebase 的決策表

自己分支整理歷史

可用 rebase，讓 commit 乾淨線性。

公共分支合併

優先 merge 或 PR/MR 的合併策略，不要私自改寫共享歷史。

衝突處理

看 conflict markers，決定保留哪一方或兩方整合。

git merge feature/ui-redesign
# 衝突後：手動刪除 <<<<<<< ======= >>>>>>> 標記
git add resolved-file
git merge --continue

# 整理個人分支：
git rebase main
git rebase --continue
# 已推送分支真的要強推：
git push --force-with-lease
GitHub 網頁 conflict editor 只適合簡單行衝突；刪檔、改檔、二進位、子模組、複雜多檔請回本機。
merge --abort 與 rebase --abort 是救命鍵；出錯先停，不要亂試。
☁️
第 05 章

Remote 遠端倉庫

Remote 是本機對雲端倉庫的地址簿，預設常叫 origin。

本地 repo工作區 + .gitorigin/mainGitHub / GitLabgit pushgit fetch / pull
git remote add origin git@github.com:your-name/repo.git
git remote -v
git push -u origin main
如果本地已經有 commit，建立 GitHub/GitLab 空 repo 時不要勾初始化 README，避免第一次 push 出現 unrelated histories。

☁️ 深化：origin / upstream 不要混淆

origin

通常是你的遠端倉庫。clone 時 Git 自動建立。

upstream

fork 專案時，常用來指原作者倉庫。

remote tracking branch

origin/main 是遠端狀態在本地的鏡像，不是你直接編輯的分支。

git remote -v
git remote add upstream https://github.com/original/repo.git
git fetch upstream
git switch main
git merge upstream/main
git push origin main
本地已經有 commit 時，遠端空 repo 不要先勾 README，避免 unrelated histories。
HTTPS 適合快速開始；SSH 適合長期使用與多專案協作。
🔁
第 06 章

Fetch / Pull / Push

Fetch 只拿消息；Pull 拿消息並合入；Push 是把你的版本推到遠端。

👀 git fetch

像先看雲端有什麼新內容，不動你的工作分支。

📥 git pull

像拿雲端新內容並合進來，可能衝突。

📤 git push

把本地 commit 更新到遠端，會改變共享倉庫。

git fetch origin
git log main..origin/main --oneline
git pull --ff-only
git push --force-with-lease   # 必須強推時，比 --force 安全
pull.autostash：pull 前自動暫存未完成工作，pull 後再取回；這跟 Git 2.51 的 stash import/export 不是同一件事。

🔁 深化：fetch / pull / push 的風險不同

fetch 最安全

只更新遠端追蹤分支，不碰你的工作分支。

pull 可能衝突

會合入或 rebase，因此可能讓你立即處理衝突。

push 影響別人

更新共享遠端，main 分支更要小心。

git fetch origin
git log --oneline main..origin/main
# 確認差異後再合入
git merge origin/main

# 初學可用 merge；偏線性可用 rebase
git pull --rebase
# 只允許快轉，避免意外 merge commit
git pull --ff-only
pull.autostash 是早已有的設定，不是 Git 2.51 新功能；Git 2.51 新增的是 stash import/export。
--force 會覆蓋遠端歷史，必要時用 --force-with-lease 並先告知團隊。
🔍
第 07 章

Pull Request / Merge Request

PR/MR 是「我要把我的分支合進主線，請大家審查」的協作流程。

🌿 開分支
💻 開發 commit
☁️ push
🔍 PR/MR Review
✅ CI 通過後合併

GitHub Rulesets

可針對 branch、tag、push 設規則：要求 PR、狀態檢查、簽名、限制 force push。

Web Conflict Editor 限制

只適合簡單行衝突；刪檔、改檔、二進位、子模組、複雜多檔要回本機解。

🔍 深化：PR/MR 是「技術 + 溝通 + 治理」

標題

讓審查者一眼知道目的，例如 feat: add checkout coupon。

說明

寫清楚背景、修改內容、測試方式、風險。

規則

Rulesets / status checks / required reviewer 讓重要分支不被亂改。

git switch -c feature/payment-coupon
git add -p
git commit -m "feat: add coupon validation"
git push -u origin feature/payment-coupon
# 接著到 GitHub/GitLab 開 PR/MR
GitHub Rulesets 可管理 branch、tag、push；Required reviewer rule 已 GA，可要求特定團隊審核特定路徑。
CODEOWNERS 管「誰擁有」；Required reviewer rule 管「哪些變更一定要誰核准」。兩者不是彼此取代。
🔐
第 08 章

SSH Key

SSH Key 像一組「公鑰門牌 + 私鑰鑰匙」。公鑰貼平台，私鑰只留自己電腦。

私鑰留在 ~/.ssh公鑰貼到 GitHub/GitLab配對驗證，不傳私鑰
ssh-keygen -t ed25519 -C "you@example.com"
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh -T git@github.com
ssh -T git@gitlab.com
私鑰不要貼到 README、不要傳給同事、不要上傳到 repo。需要多帳號就用 ~/.ssh/config 分開。

🔐 深化：SSH Key 的安全習慣

公鑰

可以貼到 GitHub/GitLab，像門牌。

私鑰

絕不外傳，像你家的鑰匙。

Passphrase

私鑰被偷後的最後一道防線。

ssh-keygen -t ed25519 -C "you@example.com"
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh -T git@github.com
ssh -T git@gitlab.com
一台設備一把 key，換機或離職就撤銷舊 key。
多帳號可用 ~/.ssh/config 指定不同 IdentityFile；企業可考慮 FIDO2 / YubiKey。
🏷️
第 09 章

Tag 與 SemVer

Tag 是固定版本標記；SemVer 讓別人看版本號就知道這次改動嚴重程度。

2.1.3-beta.1
點按鈕看版本如何變化。
git tag -a v1.0.0 -m "Release v1.0.0"
git push --follow-tags

🏷️ 深化：版本號是對使用者的承諾

MAJOR

不相容變更，例如 API 改掉舊程式不能用。

MINOR

向下相容的新功能。

PATCH

向下相容的 bug 修復。

git tag -a v1.4.0 -m "Release v1.4.0"
git push origin v1.4.0
# 只推送 annotated tag：
git push --follow-tags
# 依版本排序：
git tag --sort=-version:refname
正式發布建議用 annotated tag；lightweight tag 可用於臨時標記。
預發布可用 v2.0.0-beta.1，正式版 v2.0.0 的優先順序高於 beta。
🪝
第 10 章

Git Hooks

Hooks 是在 commit、push 前後自動執行的小檢查。像是送出前的守門員。

✏️ 修改
📥 add
🪝 pre-commit 檢查
📦 commit
🧪 CI 再檢查

Client-side hooks

本機執行，方便提醒；但可被 --no-verify 跳過。

CI/CD

遠端執行，更適合做不可跳過的安全與品質檢查。

pip install pre-commit
pre-commit install
pre-commit run --all-files

🪝 深化：Hooks 是便利，不是唯一安全防線

pre-commit

commit 前檢查格式、測試、secret。

commit-msg

檢查 commit message 是否符合規則。

pre-push

push 前跑測試；但本地 hook 可能被跳過。

pip install pre-commit
pre-commit install
pre-commit run --all-files

# Git 2.54：可集中設定 hooks path
git config core.hooksPath .githooks
--no-verify 可跳過 client-side hooks，所以安全檢查仍要放在 CI/CD 或伺服器端。
團隊建議把 hook 設定檔納入 repo，讓新人 clone 後能快速套用。
🏢
第 11 章

GitLab 基礎與 19.x 升級風險

GitLab 更像完整 DevSecOps 平台；自建很強，但升級與維運風險也更高。

Group：公司 / 團隊
├─ Project：frontend-web
│ ├─ Merge Requests
│ ├─ CI/CD Pipeline
│ └─ Container Registry
├─ Project：backend-api
└─ Project：infra-tools

📊 GitLab 19 自建升級注意力圖

PostgreSQL 17
高
Redis/OS 支援
高
Helm/Ingress
中高
價格/配額
變動
自建 GitLab 不是只會 Git 就能維護；正式升級前要看官方 release notes、backup、PostgreSQL、Runner、CI/CD、儲存與 downtime 策略。

🏢 深化：GitLab 自建升級前先做體檢

資料庫

GitLab 19.0 最低 PostgreSQL 17。未升級不能冒進。

OS / Redis

Ubuntu 20.04、SUSE 套件、Redis 6 支援變更需預先處理。

Helm / Ingress

Helm chart 改用 Gateway API + Envoy，舊 NGINX Ingress 需規劃。

# 升級前檢查思路（非直接貼上執行）
1. 完整備份 GitLab、PostgreSQL、repositories
2. 查目前版本 → 查所有跨版本 upgrade notes
3. 確認 PostgreSQL 17、Runner、CI/CD、儲存、網路
4. 測試環境先跑升級
5. 正式環境安排維護窗口
GitLab 19.0.2 已於 2026-06-10 發布重要安全修補，自建版應依官方建議更新到支援線最新版。
不要在教學中寫死 GitLab Pricing、CI 分鐘數或配額，這類資訊最容易變動。
⚙️
第 12 章

大型 Repo 與維護

Repo 變大後，要用 maintenance、gc、partial/shallow clone、sparse checkout 減少負擔。

🧹 maintenance

排程整理物件，讓 repo 保持健康。

📉 shallow clone

只拿最近歷史，適合 CI 或快速查看。

🎯 sparse checkout

大 repo 只取你需要的資料夾。

git maintenance start
git maintenance run
git clone --depth 1 https://github.com/user/repo.git
git sparse-checkout init --cone
git sparse-checkout set src docs

⚙️ 深化：大型 Repo 的三種減重方式

Shallow

只拿最近歷史，CI 快速跑很適合。

Partial

先不拿所有 blob，需要時再取。

Sparse

只檢出需要的資料夾。

git maintenance start
git maintenance run

git clone --depth 1 https://github.com/user/repo.git
git clone --filter=blob:none https://github.com/user/repo.git
git sparse-checkout init --cone
git sparse-checkout set src docs
Git 2.54 的 maintenance 預設採用 geometric repacking，有助大型 repo 維護。
git history 仍屬 experimental，教學中應標示，不把它寫成全面取代 git log/reflog。
✅
第 13 章

最佳實踐與危險命令

真正厲害不是背很多命令，而是知道什麼時候不能亂按。

✅ 好習慣

  • commit 前看 git diff
  • 小 commit、訊息清楚
  • 密碼、token、.env 不進 repo
  • 公共分支避免強推

⚠️ 危險命令

  • git reset --hard
  • git clean -fd
  • git push --force
  • 亂改已推送歷史
git status -sb
git diff
git add -p
git commit -m "feat: add customer search filter"
git worktree add ../project-hotfix hotfix

✅ 深化：好 commit 是未來自己的救命索引

小 commit

一個 commit 解決一件事，日後追錯容易。

清楚 message

用 feat/fix/docs/chore 等前綴。

先保護秘密

.env、token、憑證不要入 repo；若已提交要清歷史並輪換。

git status -sb
git diff
git add -p
git commit -m "fix: prevent duplicated form submit"

# 危險命令前先確認
git reset --hard
git clean -fd
git push --force-with-lease
.gitignore 只能阻止未被追蹤的檔案；已 commit 的秘密不會因為加入 .gitignore 自動消失。
git worktree 適合同時處理 hotfix 與 feature，不必一直 stash / switch。
🧪
第 14 章

Plus：Submodule / Cherry-pick / Patch

進階命令像工具箱：平常不用全背，但遇到特定情況非常好用。

main-repo/
├─ app/
├─ docs/
└─ vendor/theme/ ← submodule：另一個 repo 的特定版本
🧷 submodule

把另一個 repo 固定在專案裡。

🍒 cherry-pick

只摘一筆 commit 到目前分支。

📨 patch

把變更打包給別人套用。

git cherry-pick a1b2c3d
git format-patch -1 HEAD
git apply fix.patch
git submodule update --init --recursive
Git 2.54 的 git history 屬 experimental，不要把它當成已全面取代現有流程。

🧪 深化：進階命令不是炫技，是急救工具

Submodule

把另一個 repo 固定在目前專案的特定版本。

Cherry-pick

只摘取某一筆 commit 到目前分支。

Patch

把變更打包成檔案，適合跨系統傳遞或審查。

git submodule update --init --recursive
git cherry-pick a1b2c3d
git format-patch -1 HEAD
git apply fix.patch
# 找出哪一版引入 bug：
git bisect start
Submodule 適合固定外部依賴，但新手常忘記初始化與更新。
Cherry-pick 可能衝突，也會產生新 commit hash；不要以為它是原 commit 原封不動搬家。

🧭 我想做什麼？命令決策器

點上方卡片，這裡會產生你需要的命令與注意事項。

🎯 隨機 15 題測驗小遊戲

每次從題庫抽 15 題。全對：你很棒；10-14 題：臨門一腳；5-9 題：不太熟喔；0-4 題：要好好加強。

🧾 速查字典

🔎 官方查核來源與教材依據

  • 上傳教材：Git / GitHub / GitLab 完全教程，2026-06-02 官方查驗版・融合精校版。
  • Git 官方首頁：Latest source release 為 2.54.0，Release Notes 日期 2026-04-20。
  • Git for Windows 官方頁：最新維護版為 2.54.0 x64，發布日期 2026-04-20。
  • GitHub Docs：Rulesets 可套用 branch / tag / push；push rulesets 可阻擋 private/internal repo 與 fork network 的推送。
  • GitHub Changelog：Required reviewer rule 於 2026-02-17 generally available；可依路徑與團隊設定必要審查。
  • GitHub Docs：Web conflict editor 僅能解簡單 competing line changes；複雜衝突要回本機命令列。
  • GitLab Docs：GitLab 19.0 在 2026-05-21 發布；自建升級需注意 PostgreSQL 17 最低要求、Ubuntu 20.04 / SUSE / Redis 6 / Mattermost / Helm chart 元件移除與 Envoy Gateway 變更。
  • GitLab Docs：GitLab 19.0.2、18.11.5、18.10.8 於 2026-06-10 發布，包含重要 bug 與 security fixes；自建安裝建議立即升級到對應 patch。
  • SemVer.org：Semantic Versioning 2.0.0 官方規格。
教學處理原則：stable、experimental、planned、deprecated 分開寫；未來預告不當成既成事實；易變動的價格、配額、支援表不寫死，改提示讀者查官方頁。
製作日期：2026-06-13｜設計目標：非工程背景也能用圖像與情境理解 Git。