測驗：GitHub Flow – 合併與部署
共 5 題，點選答案後會立即顯示結果
1. 在 GitHub 上合併 PR 之前，需要確認哪些條件都通過？
2. 「Squash and merge」合併策略的特點是什麼？
3. 合併 PR 後，為什麼建議刪除 feature 分支？
4. 在 CI/CD 流程中，CI（持續整合）的主要功能是什麼？
5. 當遇到合併衝突時，以下哪個描述是正確的？
<<<<<<< feature-branch
return "Hello, World!"
=======
return "Hi, World!"
>>>>>>> main
一句話說明
把審核通過的程式碼合併到 main 分支，然後部署上線。
這篇教你看懂什麼
讀完這篇，你能看懂：
- 合併前要檢查什麼
- Merge、Squash、Rebase 三種合併按鈕的差別
- 合併後為什麼要刪除分支
- GitHub Flow 怎麼跟自動部署配合
合併前的檢查清單
在 GitHub 上看到 PR 頁面，合併前確認這些：
+------------------------+
| Pull Request #42 |
+------------------------+
| Status Checks |
| [x] CI passed | <-- 自動測試要過
| [x] Review approved | <-- 要有人批准
| [x] No conflicts | <-- 不能有衝突
+------------------------+
| [Merge pull request] | <-- 全部綠勾才能點
+------------------------+
Code language: PHP (php)翻譯：
- CI passed：自動化測試跑過了，程式碼沒有明顯 bug
- Review approved：至少一個人看過並批准
- No conflicts：你的修改跟 main 分支沒有衝突
三種合併策略
點「Merge pull request」旁邊的箭頭，會看到三個選項：
選項 1：Create a merge commit（預設）
main: A---B-----------M
\ /
feature: C---D---E
翻譯：保留所有 commit 歷史，產生一個合併點 M。
適合場景：
- 大部分情況都用這個
- 想保留完整開發過程
選項 2：Squash and merge
main: A---B---S
feature: C---D---E (這些會被壓成一個 S)
Code language: HTTP (http)翻譯：把 feature 分支的所有 commit 壓成一個。
適合場景：
- commit 太多太雜亂
- 只想保留「做了什麼」，不需要「怎麼做的」
選項 3：Rebase and merge
main: A---B---C'---D'---E'
feature: C---D---E (複製一份接到 B 後面)
Code language: HTTP (http)翻譯：把 feature 的 commit 複製一份，接在 main 後面，變成直線。
適合場景：
- 想要乾淨的直線歷史
- 需要進階 Git 知識
常見選擇指南
| 情況 | 建議選擇 | 原因 |
|---|---|---|
| 不知道選什麼 | Merge commit | 最安全，保留全部歷史 |
| 修改很小（1-3 commits） | Squash | 合成一個更清楚 |
| commit 很亂有很多「fix typo」 | Squash | 清理掉雜亂歷史 |
| 想要直線歷史 | Rebase | 但要確定沒人在用這分支 |
實際操作：合併 PR
步驟 1：確認檢查都通過
看到這個畫面才能合併：
All checks have passed
2 successful checks
Review required
Changes approved
1 approving review
This branch has no conflicts with the base branch
Code language: JavaScript (javascript)步驟 2：選擇合併方式
點綠色按鈕旁邊的下拉箭頭，選擇策略（通常用預設就好）。
步驟 3：點「Merge pull request」
+----------------------------------+
| Merge pull request |
+----------------------------------+
| Add a title (optional) |
| [Merge pull request #42] |
| |
| Add a description (optional) |
| [ ] |
| |
| [Confirm merge] |
+----------------------------------+
Code language: PHP (php)步驟 4：刪除分支
合併後會出現：
Pull request successfully merged and closed
[Delete branch] <-- 點這個
Code language: CSS (css)為什麼要刪除？
- 這個分支的工作已經完成
- 避免分支越積越多
- main 已經有這些程式碼了
GitHub Flow 與 CI/CD
什麼是 CI/CD
CI（持續整合） CD（持續部署）
| |
v v
[程式碼推送] --> [自動測試] --> [自動部署]
翻譯：
- CI：每次推程式碼，自動跑測試
- CD：測試通過後，自動部署到伺服器
GitHub Flow + CI/CD 流程
1. 開分支改程式碼
|
v
2. 推到 GitHub，開 PR
|
v
3. CI 自動跑測試 <-- 自動的
|
v
4. 審核通過，合併到 main
|
v
5. CD 自動部署上線 <-- 自動的
在 GitHub 上看起來像這樣
Pull Request #42
Checks
+----------------------------------+
| [x] build (3m 42s) |
| [x] test (5m 18s) |
| [x] lint (1m 03s) |
+----------------------------------+
^^ 這些都是 CI 自動跑的
Code language: PHP (php)合併後：
GitHub Actions
deploy (2m 15s) - completed <-- CD 自動部署
常見問題：合併衝突
什麼時候會發生
你改 A 檔案的第 10 行，同時別人也改了第 10 行，而且先合併了。
This branch has conflicts that must be resolved
Conflicting files:
- src/app.py
怎麼看懂衝突標記
GitHub 會顯示：
def greeting():
<<<<<<< feature-branch
return "Hello, World!"
=======
return "Hi, World!"
>>>>>>> main
Code language: JavaScript (javascript)翻譯：
<<<<<<< feature-branch：你的版本開始=======：分隔線>>>>>>> main：main 的版本- 你要決定保留哪個（或合併兩個）
解決衝突
- 點「Resolve conflicts」
- 手動編輯，決定要保留什麼
- 刪掉
<<<<<<<、=======、>>>>>>>標記 - 點「Mark as resolved」
- 點「Commit merge」
Vibe Coder 檢查點
合併 PR 時確認：
- [ ] CI 測試都通過了嗎？（綠勾）
- [ ] 有人審核並批准了嗎？
- [ ] 沒有合併衝突嗎？
- [ ] 合併後刪除分支了嗎？
看到合併衝突時確認：
- [ ] 知道
<<<<<<<和>>>>>>>之間是什麼嗎？ - [ ] 決定好要保留哪個版本了嗎？
- [ ] 刪除衝突標記了嗎？
系列回顧：GitHub Flow 完整流程
1. 從 main 開分支
git checkout -b feature-xxx
|
v
2. 在分支上開發
git add . && git commit
|
v
3. 推送並開 PR
git push -u origin feature-xxx
|
v
4. 程式碼審查
同事看程式碼、留評論、批准
|
v
5. 合併到 main（本篇重點）
點 Merge pull request
|
v
6. 刪除分支
點 Delete branch
|
v
7. 自動部署（如果有設定）
恭喜你學完 GitHub Flow！
這就是業界最常用的協作流程。重點是：
- main 永遠保持可部署狀態
- 所有修改都透過 PR 進行
- 每個 PR 都要經過審核
延伸：知道就好
這些進階功能遇到再查：
- Protected branches：保護 main 不被直接 push
- Required reviewers：強制要求特定人審核
- Status checks：設定必須通過的 CI 檢查
- Auto-merge：審核通過後自動合併
進階測驗：GitHub Flow – 合併與部署
測驗目標：驗證你是否能在實際情境中應用所學。
共 5 題，包含情境題與錯誤診斷題。
共 5 題，包含情境題與錯誤診斷題。
1. 你的 PR 有 20 個 commit，其中很多是「fix typo」、「update」這類小修正。團隊希望 main 的歷史保持乾淨，你應該選擇哪種合併策略？ 情境題
2. 同事小美想合併她的 PR，但 GitHub 顯示以下訊息。她應該先做什麼？ 錯誤診斷
This branch has conflicts that must be resolved
Conflicting files:
– src/config.js
3. 你的團隊剛導入 CI/CD，PR 頁面顯示以下狀態。這代表什麼意思？ 情境題
Checks
+———————————-+
| [x] build (3m 42s) |
| [x] test (5m 18s) |
| [ ] lint (failed) |
+———————————-+
4. 小明在解決合併衝突時，看到以下程式碼。他想要同時保留兩個功能，應該怎麼處理？ 錯誤診斷
def greeting(name):
<<<<<<< feature-branch
return f"Hello, {name}! Welcome!"
=======
return f"Hi, {name}!"
>>>>>>> main