本週完成成果
這一週，你會和組員共用同一個 Repo，但每個人先在自己的 branch 工作，再用 Pull Request 請隊友檢查。你不只會按 Merge，也會留下別人看得懂的修改理由與 Review 紀錄。
完成標準｜每位組員有自己的 feat-姓名分支；小組至少完成一個 Pull Request、一次有內容的 Review，以及合併後可在 main 看到的 proposal_draft.md。
課前準備
步驟 1｜GitHub 網頁：確認已加入教師指定的小組 Repo，首頁顯示正確組名與成員。
預期結果｜每位成員都能看到 Repo；沒有權限的人先停止，不要借同學帳號操作。
步驟 2｜Codespaces 終端機：更新 main 並確認工作目錄乾淨。
git switch main
git pull --ff-only
git status --short預期結果｜最後沒有列出未提交檔案；若 pull 失敗，先把自己的修改保存到個人分支。
步驟 3｜小組口頭分工：指定一人整理問題、一人整理使用者、一人整理初步解法，記在 issue 或 proposal_draft.md 頂端。
預期結果｜每個人能用一句話說明自己負責的段落，避免三個人同時改同一行。
第二、三小時｜課堂教材與個人技術實作
故事開始｜三位同學約好一起寫提案，卻在群組裡傳出 proposal_final、proposal_final2、proposal_真的完成版。到了晚上，沒有人知道哪一份才包含所有人的修改。Git branch 就像讓每個人先拿一張透明描圖紙，各自畫完，再把差異疊回共同底稿。
老師先問｜每個人直接修改 main 不是比較快嗎？快只發生在第一分鐘；當兩人同時改同一段，沒有人先說明或檢查，後面找回正確版本通常更慢。
生活比喻｜branch 是自己的工作桌，Pull Request 是把作品放到小組桌上說「請幫我看」，Review 是同學貼便條紙，Merge 才是大家同意後放進正式資料夾。
先看全程地圖｜先看懂資料與決策怎麼移動，再開始操作。圖中的箭頭代表下一步，不代表可以跳過人工確認。
┌──────────┐ ┌──────────┐ ┌──────────┐
│ main 最新版│ → │ 個人 branch│ → │ commit 說明│
└──────────┘ └──────────┘ └────┬─────┘
↓
┌──────────┐ ┌──────────┐ ┌──────────┐
│ main 新版本│ ← │ Merge │ ← │ PR + Review│
└──────────┘ └──────────┘ └──────────┘步驟 4｜Codespaces 終端機：以自己的英文名字建立分支，不要照抄範例姓名。
git switch -c feat-your-name
git branch --show-current預期結果｜顯示 feat-your-name 的個人化名稱，且不在 main 上直接改作業。
步驟 5｜編輯器：在 proposal_draft.md 只完成自己負責的一段，並在 week03_git_concept.md 用自己的話解釋 branch、PR、Review、Merge。
# 提案草稿
## 我們觀察到的生活問題
## 主要使用者
## 初步解法
## 還需要查證的假設預期結果｜內容可由組員讀懂，而且沒有貼入 AI 直接生成卻未核對的整篇文字。
步驟 6｜Codespaces 終端機：只加入本次修改，commit 並推送個人分支。
git add week03_git_concept.md proposal_draft.md
git commit -m 'W3: add problem and user draft'
git push -u origin HEAD預期結果｜GitHub 出現同名分支，commit 說明能讓隊友知道改了什麼。
步驟 7｜GitHub 網頁：建立 Pull Request；隊友開 Files changed，留下一個指出優點的 Comment 和一個可執行的修改建議。作者修改後再請 Review。
預期結果｜PR 對話中留下修改前後的理由；核准者不是作者本人。
課堂收束｜請每組用一分鐘演出「作者、Reviewer、main 守門員」三個角色。合併不是誰職位最大，而是證據顯示修改已看過、問題已處理。
指定閱讀與課後作業
指定閱讀｜依課綱完成 W3Schools Git Tutorial 從 Git Get Started 到 Git Branch；閱讀用來補強名詞，課堂的 PR 與 Review 操作仍以 GitHub 官方文件為準。
課後作業方向｜把課堂尚未完成的提案段落補齊，至少再回應一次 Review。不要為了留下紀錄而寫「OK」；請說明你改了什麼或為什麼暫不修改。
步驟 8｜個人：完成 week03_git_concept.md，加入一張自己畫的分支流程與一個可能發生衝突的例子。
預期結果｜不能只貼定義；必須用小組本週實際操作解釋。
步驟 9｜小組：更新 proposal_draft.md，完成 Review 後由指定成員 Merge，再同步 main。
git switch main
git pull --ff-only
git log --oneline --decorate -5預期結果｜main 的最近紀錄可找到已合併 PR，兩份必交檔案都存在。
驗收方式
git branch --show-current
git log --oneline --all --decorate -8
test -f week03_git_concept.md && test -f proposal_draft.md
git status --short通過條件｜能指出自己的 branch、PR 連結、Review 紀錄與合併 commit；main 含兩份檔案且工作目錄乾淨。
應提交的 Repo 檔案
必交｜week03_git_concept.md、proposal_draft.md。只提交課綱指定成果與重現所需說明；不得提交 API key、個資、私人對話、未授權資料或大型模型檔。
常見問題與排除
問題 1｜merge conflict：先停下來讀衝突標記，和另一位作者確認要保留的內容；不要整份覆蓋。
問題 2｜push rejected：先確認目前 branch，再用 git pull --rebase 或依老師指示同步；不要 force push 共用 main。
問題 3｜PR 沒有差異：通常是分支沒有 commit，或 base/head 選反；先查看 Commits 與 Files changed。
引用資料
國立中央大學授課課綱／劉書銘老師，《劉書銘老師課程大綱_基礎模型與生成式人工智慧-更新版.pdf》；教師提供附件。用途：W1–W16 時段、實作主題、評量與交付物。
GitHub Docs，《About pull requests》；https://docs.github.com/en/pull-requests/get-started/about-pull-requests；查閱日期：2026-08-04。用途：W3 branch、Pull Request、討論與合併協作流程。
GitHub Docs，《Quickstart for reviewing pull requests》；https://docs.github.com/en/pull-requests/get-started/reviewing-pull-requests-quickstart；查閱日期：2026-08-04。用途：W3 Code Review 留言、建議、核准與要求修改。
Git project，《gittutorial》；https://git-scm.com/docs/gittutorial；查閱日期：2026-08-04。用途：status、add、commit 與版本紀錄基本流程。
W3Schools（課綱指定閱讀），《Git Tutorial》；https://www.w3schools.com/git/；查閱日期：2026-08-04。用途：W3 課後 Git Get Started 至 Git Branch 指定閱讀。