LESSON 02 · 午餐揪團頁主線

交付的作業系統：Git・GitHub・Issue・PR

把第 1 堂「跟著手勢做」的動作講清楚，並確立這門課接下來的規則：所有作業都用 PR 交、所有問題都用 issue 提。這不只是交作業的形式，這就是你以後跟真正的工程團隊合作的樣子。

協作習慣建立 issue + PR 迴圈互評 review 課後完成產出：1 issue + 1 PR

✓

完成定義 · Definition of Done

學員能獨立完成「開 issue → 開分支 → commit → 開 PR 對應 issue」的完整迴圈。從今天起，每一份作業都是這個迴圈的一次練習。

0:00–0:05	回顧第 1 堂：昨天做了什麼「魔法動作」
0:05–0:15	Git 心智模型（存檔點 / 時光機 / 平行時空）
0:15–0:20	單次 commit 示範（不做來回跳版本練習）
0:20–0:30	GitHub + 好壞 issue 範例對照
0:30–0:40	每人寫一張 issue（重點：標題 + 現況 / 期待）
0:40–0:45	PR 概念、怎麼寫好的 PR 描述
0:45–0:55	完整走一次：領 issue → 分支 → AI 改功能 → commit → PR
0:55–1:00	收尾：宣告「從今天起所有作業都這樣交」

01Git 心智模型

玩過遊戲都知道：你不會每走一步就存檔，你會在破完一關、或要挑戰危險任務前存檔——因為存檔的意義是「這裡是一個我想得回的點」。

COMMIT

存檔點

做完一個有意義的小段落，就存一次：「這裡，我想記住這個版本。」

HISTORY

時光機

所有存檔點串起來。隨時可以回到任何一個，改壞了也不怕。

BRANCH

平行時空

想試危險打法？開個副本去試，成功再帶回正式線（main）。

圖 1.1Git 三個核心概念：commit 存檔點、history 時光機、branch 平行時空。

02單次 commit 示範

在自己第 1 堂的分支上改一個小地方（例如換一個顏色），存一次 commit。然後看 history——你剛剛建立了一個存檔點，隨時可以回來。「不怕改壞」的安全感就是從這裡來的。

03GitHub 與好 Issue

Git 是你自己的時光機；GitHub 是把所有人的時光機放在同一個地方的平台——工程師才看得到你做了什麼，你也看得到工程師做了什麼。

📋一張好 issue 的四要素

① 標題一句話講清楚是什麼事。② 現況 vs 期待：現在長怎樣、你希望它變怎樣。③ 重現步驟（如果是問題回報）。④ 截圖（跟畫面有關就附上）。好的 issue 讓對方不用來回問就能開始處理。

對照練習：標題「這個壞了」＋內容空白 → 工程師完全無法處理。標題「揪團卡的『我要跟』按鈕點兩下人數會跳兩次」＋重現步驟＋截圖 → 馬上能開工。

04PR 與完整迴圈

Issue 是「提出想法」，PR 是「提出改好的成果」。一個好的 PR 描述回答三件事：改了什麼、為什麼改、怎麼驗證。

圖 4.1完整的協作迴圈：issue 提出 → 分支實作 → PR 交付 → review 合併。

兩兩配對：把你寫的 issue 交給對方「接單」——開分支 → 用 AI 實作 → commit → 開 PR 連結對應的 issue（例如 Closes #12）。這就是完整的協作迴圈，以後你兩種角色都會做。

課後作業：前往至少一位同學的 PR，留下一句鼓勵 + 一句具體回饋（例如「這裡的顏色我很喜歡」「這個按鈕文字可以更清楚」）。

·AI Prompt speed dial起手式 · 用自己的話改

A依 issue 實作

這是一張 issue 的內容：
「[貼上 issue 標題與描述]」

請根據這個需求修改我目前的午餐揪團頁程式碼，
只改動需要改動的部分，並用一兩句話跟我說明你改了哪裡。

B請 AI 寫 PR 描述

我剛剛做了以下修改：[簡述你做的事]
對應的 issue 是：「[issue 標題]」

請幫我寫一段簡短的 PR 描述，包含：改了什麼、為什麼改、怎麼驗證這個改動有效。
語氣自然、不要太官腔。

C檢查 issue 寫得夠不夠清楚

我要開一張 issue 描述我想加的功能，內容如下：
「[你寫的 issue 草稿]」

請你扮演一個第一次看到這張 issue 的工程師，
告訴我有沒有看不懂的地方、缺少什麼資訊。

·作業與檢核

作業：每人至少 1 張 issue（自己寫）＋ 1 個 PR（實作別人的 issue）。課後前往至少一位同學的 PR 留言 review。

講師 / 助教檢核重點