今天我們將：
• 整理所有知識點
• 準備面試常見問題
• 給出實戰建議

一、Git 面試常見問題
基礎概念題
Q1: 解釋 Git 和 GitHub 的差別
A:
Git：

• 版本控制系統
• 在本地運作
• 追蹤程式碼變更

GitHub：

• Git 的託管平台
• 雲端服務
• 提供協作功能（PR, Issues）
• 社群和開源專案

類比：
Git 就像 Word（軟體）
GitHub 就像 Google Docs（服務）
Q2: Git 的三個區域是什麼？
A:

1. Working Directory（工作目錄）

   • 實際編輯檔案的地方

2. Staging Area（暫存區）

   • git add 後的檔案放這裡
   • 準備提交的快照

3. Repository（倉庫）

   • git commit 後永久儲存
   • .git 目錄

流程：
編輯 → git add → Staging → git commit → Repository
Q3: 什麼是 commit？
A:
Commit 是專案某個時間點的快照

包含：

• 檔案變更內容
• 作者資訊
• 時間戳記
• Commit 訊息
• 父 commit 的指標（形成歷史鏈）

好的 commit：

• 原子性（一次只做一件事）
• 有意義的訊息
• 可以獨立回退
  Q4: HEAD 是什麼？
  A:
  HEAD 是指向當前所在位置的指標

通常情況：
HEAD → 分支 → commit
例：HEAD → main → abc123

Detached HEAD：
HEAD 直接指向某個 commit
發生於：git checkout

檢查：
cat .git/HEAD

分支與合併題
Q5: 解釋 merge 和 rebase 的差別
A:
Merge：

• 保留完整歷史
• 產生 merge commit
• 歷史像樹狀結構
• 更安全

Rebase：

• 重寫歷史
• 線性歷史
• 沒有 merge commit
• 更乾淨但有風險

使用時機：
Merge：合併公開分支（main, develop）
Rebase：整理自己的 feature 分支

黃金法則：
永遠不要 rebase 已推送的公開分支！
Q6: Fast-forward merge 是什麼？
A:
當目標分支沒有新的 commits 時發生

範例：
main: A - B
feature: B - C - D

merge 後：
main: A - B - C - D（只是移動指標）

沒有產生 merge commit，直接快轉

禁用：
git merge --no-ff feature
強制產生 merge commit，保留分支歷史
Q7: 如何解決 merge 衝突？
A:
步驟：

1. git merge feature（發生衝突）
2. git status（查看衝突檔案）
3. 手動編輯衝突檔案
   • 移除 <<<<<<<, =======, >>>>>>> 標記
   • 保留需要的內容
4. git add 解決的檔案
5. git commit

預防：

• 頻繁同步 main
• 小而頻繁的 commits
• 良好的程式碼組織
• 溝通協調

協作與遠端題
Q8: git pull 和 git fetch 的差別？
A:
git fetch：

• 只下載遠端的變更
• 不會自動合併
• 安全，可以先檢查

git pull：

• fetch + merge
• git pull = git fetch + git merge
• 會自動合併，可能產生衝突

建議：
使用 git fetch 後檢查
確認沒問題再 merge
Q9: 什麼時候用 git push --force？
A:
⚠️ 非常危險的操作！

可以用的情況：
✅ 自己的 feature 分支
✅ 整理完歷史後
✅ 確定沒有其他人在用

絕對不要：
❌ 公開分支（main, develop）
❌ 團隊共用的分支

更安全的替代：
git push --force-with-lease
（會檢查遠端是否被更新）
Q10: 什麼是 Pull Request？
A:
Pull Request（PR）：

• 請求將分支合併到另一個分支
• 在 GitHub/GitLab 上進行
• 不是 Git 本身的功能

PR 的好處：

• Code Review
• 討論和回饋
• CI/CD 檢查
• 保護主要分支

流程：

1. 建立 feature 分支
2. 開發並 push
3. 在 GitHub 建立 PR
4. Code Review
5. 測試通過
6. 合併到 main

進階題
Q11: 解釋 git reset 的三種模式
A:

1. --soft
   只移動 HEAD
   變更留在 Staging Area
   用途：重新 commit

2. --mixed（預設）
   移動 HEAD + 重設 Staging
   變更留在 Working Directory
   用途：取消 git add

3. --hard
   移動 HEAD + 重設 Staging + Working
   變更完全消失
   用途：完全回到某個狀態

範例：
git reset --soft HEAD~1 # 撤銷 commit，保留變更
git reset HEAD~1 # 撤銷 commit 和 add
git reset --hard HEAD~1 # 完全刪除最後 commit
Q12: 如何找回誤刪的 commit？
A:
使用 git reflog

步驟：

1. git reflog
   查看所有 HEAD 移動記錄

2. 找到誤刪前的 commit hash
   例：abc123 HEAD@{2}: commit: 重要功能

3. 恢復
   git reset --hard abc123
   或
   git cherry-pick abc123

Reflog 保留時間：
預設 90 天
可設定：git config gc.reflogExpire "180 days"
Q13: cherry-pick 的用途？
A:
Cherry-pick：
複製某個 commit 到當前分支

使用場景：

1. Hotfix 需要套用到多個分支
   git checkout release/v1.0
   git cherry-pick

2. 只要某個功能的部分 commits
   git cherry-pick commit-A commit-C

3. 從錯誤分支救回 commit
   git checkout correct-branch
   git cherry-pick

注意：
產生新的 commit（不同 hash）
可能產生衝突
Q14: stash 的使用時機？
A:
Stash 暫存未完成的工作

使用時機：

1. 需要切換分支但工作未完成
2. 突然要修 hotfix
3. pull 之前有未提交的變更
4. 想暫時清空工作區

常用指令：
git stash push -u -m "描述" # 暫存（包含新檔案）
git stash list # 查看列表
git stash pop # 恢復並刪除
git stash apply # 恢復但保留

技巧：
可以有多個 stash
可以在不同分支 pop
Q15: 如何寫好 commit 訊息？
A:
Conventional Commits 格式：

():

Type：

• feat: 新功能
• fix: 修復 bug
• docs: 文件
• style: 格式（不影響程式碼）
• refactor: 重構
• test: 測試
• chore: 雜項

範例：
feat(auth): 新增 Google 登入功能

實作 OAuth 2.0 整合，使用者可以用 Google 帳號登入。

Closes #123

要點：

• 第一行 < 50 字
• 用現在式動詞
• Body 說明為什麼
• Footer 關聯 issue

二、實戰情境題
情境 1：多人同時修改同一檔案
面試官：
團隊三個人同時修改 config.js，如何避免衝突？

你的回答：

1. 預防策略：

   • 事前溝通，分配不同區域
   • 頻繁同步 main 分支
   • 小而頻繁的 commits

2. 技術策略：

   • 模組化設計，減少交集
   • 功能拆分到不同檔案
   • 使用 git rerere 記住解決方案

3. 流程策略：

   • 使用 feature branch
   • Code Review 時檢查衝突
   • CI 自動檢查可合併性

4. 發生衝突時：

   • 理解雙方的改動
   • 溝通確認解決方式
   • 充分測試後 commit
     情境 2：Production 發現嚴重 bug
     面試官：
     正式環境出現嚴重 bug，如何快速修復並部署？

你的回答：

1. 緊急處理流程：
   git checkout main
   git pull origin main
   git checkout -b hotfix/critical-bug

2. 快速修復：
   修改程式碼
   本地測試
   git commit -m "hotfix: 修復關鍵 bug"

3. 部署流程：
   git push origin hotfix/critical-bug
   建立緊急 PR
   快速 Review（但不能省略）
   合併到 main
   自動部署（CI/CD）

4. 同步到其他分支：
   git checkout develop
   git cherry-pick

5. 事後處理：

   • 記錄事件
   • 分析原因
   • 改進流程
   • 加入測試防止再發生
     情境 3：不小心 commit 到 main
     面試官：
     你不小心直接在 main commit 了，該怎麼辦？

你的回答：
情況 1：還沒 push
git branch feature/my-work # 保存到新分支
git reset --hard HEAD~1 # main 回退
git checkout feature/my-work # 繼續工作

情況 2：已經 push（更麻煩）
方法 A：Revert（推薦）
git revert HEAD
git push origin main
在 feature 分支繼續開發

方法 B：Reset + Force Push（危險）
⚠️ 只在確定沒有其他人 pull 時使用
git reset --hard HEAD~1
git push --force-with-lease origin main
通知所有團隊成員

教訓：

• 設定分支保護規則
• 使用 pre-commit hooks
• 養成檢查當前分支的習慣

三、行為面試題
團隊協作
Q: 描述一次你在團隊中使用 Git 協作的經驗

好的回答架構（STAR）：
Situation（情境）：
我們團隊 5 個人開發一個電商網站...

Task（任務）：
我負責購物車功能，需要與付款模組整合...

Action（行動）：

1. 建立 feature/shopping-cart 分支
2. 每天同步 develop 分支避免衝突
3. 拆分成小 commits，方便 Review
4. 遇到與付款模組的整合問題時，
   與負責的同事配對編程解決
5. 透過 PR 進行 Code Review
6. 根據回饋修改並最終合併

Result（結果）：

• 功能按時完成
• 零衝突
• Code Review 提升了程式碼品質
• 學到了更好的模組化設計

學到什麼：

• 溝通比技術更重要
• 小步快跑比大改更安全
• Code Review 是學習的好機會
  問題解決
  Q: 遇到過最棘手的 Git 問題是什麼？如何解決的？

範例回答：
問題：
團隊成員誤用 git push --force 覆蓋了 main 分支，
導致 20 個 commits 消失。

解決過程：

1. 保持冷靜，不要慌張
2. 使用 git reflog 找到覆蓋前的 commit
3. 透過 git reset --hard 恢復
4. 通知團隊成員重新 pull
5. 檢查是否有遺失的工作

預防措施：

1. 設定分支保護規則，禁止 force push
2. 建立 pre-push hooks 檢查
3. 團隊培訓，說明 --force 的危險性
4. 使用 --force-with-lease 替代

反思：

• 技術問題都有解決方法
• 預防勝於治療
• 團隊規範很重要

四、30 天學習總結
第一週：Git 基礎（Day 1-7）
✅ 掌握的技能：

• Git 安裝與設定
• 基本指令（add, commit, push, pull）
• 查看歷史（log, diff）
• .gitignore 使用
• 基本工作流程

核心概念：

• Working Directory → Staging → Repository
• Commit 是快照不是差異
• 分散式版本控制
  第二週：分支與合併（Day 8-14）
  ✅ 掌握的技能：
• 分支建立與切換
• merge 與 rebase
• 衝突解決
• 標籤（tags）
• Stash 暫存

核心概念：

• 分支就是指標
• Merge 保留歷史，Rebase 重寫歷史
• 衝突是正常的，不要怕
  第三週：GitHub 協作（Day 15-21）
  ✅ 掌握的技能：
• GitHub 基本操作
• Fork 與 Pull Request
• Issue 和 Project 管理
• GitHub Actions 基礎
• 團隊協作流程

核心概念：

• 開源協作模式
• Code Review 的價值
• 自動化的重要性
  第四週：實戰應用（Day 22-30）
  ✅ 掌握的技能：
• Git Flow 工作流程
• Code Review 最佳實踐
• 多人協作進階技巧
• Git 安全性
• CI/CD 整合
• 問題解決能力
• 作品集建立
• GitHub Profile 優化
• 面試準備

核心概念：

• 專業的工作流程
• 安全第一
• 持續學習與改進

五、知識地圖
Git 技能樹：

Level 1 - 基礎（必備）
├── init, clone
├── add, commit, push, pull
├── status, log, diff
└── .gitignore

Level 2 - 分支（重要）
├── branch, checkout, switch
├── merge, rebase
├── 衝突解決
└── stash

Level 3 - 協作（專業）
├── remote（add, remove, rename）
├── fetch vs pull
├── Pull Request
└── Code Review

Level 4 - 進階（大師）
├── reset, revert, cherry-pick
├── reflog
├── interactive rebase
├── Git Flow
└── CI/CD 整合

Level 5 - 專精（專家）
├── Git 內部原理
├── 效能優化
├── 自訂 hooks
├── 複雜問題解決
└── 團隊流程設計

六、下一步學習建議
鞏固基礎（1-2 週）
□ 每天使用 Git（養成習慣）
□ 建立 3-5 個完整專案
□ 練習所有常用指令
□ 嘗試解決各種問題情境
□ 寫技術筆記
提升協作（1 個月）
□ 參與開源專案（提交 PR）
□ 與他人協作開發
□ 進行 Code Review
□ 建立團隊工作流程
□ 設定 CI/CD
深入進階（持續）
□ 學習 Git 內部原理
□ 研究大型專案的工作流程
□ 優化團隊協作效率
□ 自動化流程設計
□ 分享知識（寫文章、教學）
推薦資源
書籍：

• Pro Git（免費線上版）
• Git for Teams
• 精通 Git

網站：

• https://git-scm.com/doc
• https://learngitbranching.js.org/
• https://github.com/skills

練習：

• https://www.katacoda.com/courses/git
• https://gitexercises.fracz.com/

七、實戰檢查清單
日常開發
□ 開始工作前 git pull
□ 頻繁 commit（小步前進）
□ 寫清楚的 commit 訊息
□ 定期推送到遠端
□ Code Review 認真參與
□ 遇到問題先 Google
□ 重要操作前先備份分支
專案管理
□ README 完整清楚
□ .gitignore 設定正確
□ 有明確的分支策略
□ 設定分支保護規則
□ CI/CD 自動化
□ 定期清理舊分支
□ 標籤標記重要版本
團隊協作
□ 溝通大於技術
□ 尊重 Code Review 意見
□ 及時回應 PR 和 Issues
□ 文件保持更新
□ 分享知識和經驗
□ 互相幫助學習

八、最後的挑戰

□ 初級挑戰
□ 建立一個專案並推送到 GitHub
□ 建立分支並合併
□ 解決一次 merge 衝突
□ 寫出好的 commit 訊息
□ 完成一個 Pull Request

□ 中級挑戰
□ 使用 rebase 整理 commits
□ 使用 stash 處理緊急修復
□ 從 reflog 救回誤刪的 commit
□ 設定 GitHub Actions CI/CD
□ 完成 Code Review

□ 高級挑戰
□ 貢獻開源專案（提交 PR）
□ 建立完整的作品集（3+ 專案）
□ 優化 GitHub Profile
□ 幫助他人解決 Git 問題
□ 寫一篇 Git 技術文章