Skip to content

建立 2026-09-15 更新 2026-09-15

GitHub Flow

GitHub Flow 是大多數團隊實際在用的工作方式：不要直接在 main 上改，先開一條分支，改完用 Pull Request（提取請求，常簡稱 PR）請人看過再合併。這樣 main 盡量保持可上線，出問題也比較容易回溯。

一次完整循環

flowchart LR
  A[從 main 開分支] --> B[改程式並 commit]
  B --> C[push 到 GitHub]
  C --> D[開 Pull Request]
  D --> E[審查與討論]
  E --> F[合併進 main]
  1. 從最新的 main 開一條分支，名稱說明意圖，例如 fix-login、docs/cli。
  2. 在分支上改檔、git add、git commit。一次提交做一件事，說明寫「為什麼」，不要只寫「update」。
  3. git push -u origin 分支名，把分支送到 GitHub。
  4. 開 PR：標題說做了什麼，內文說明怎麼測、對應哪個 Issue。
  5. 審查者看 diff、留言、請你改；你再 push 同一條分支，PR 會自動更新。
  6. 通過後合併。合併完可刪掉遠端分支，本機再切回 main 並 git pull。

為什麼不直接改 main

main 通常代表「目前應該能跑的版本」。直接在上面改，別人正在做的功能會被你未審查的變更打斷；出 bug 時也不知道該還原哪一次。分支把實驗關在房間裡，PR 再決定要不要開門。

Issue 與 PR 怎麼配合

Issue 用來記錄「要做的事」：bug、新功能、技術債。它不是程式本身，而是討論與追蹤。

PR 用來提出「已經寫好的變更」。一個 PR 最好對應一件事；在 PR 說明裡寫 Closes #42（或 Fixes #42），合併後 GitHub 會自動關閉該 Issue。

gh issue create --title "登入按鈕在手機版被切掉" --body "重現步驟：..."
gh pr create --title "修正手機版登入按鈕" --body "Closes #42"

網頁操作等價：Repo 的 Issues 分頁開新 Issue；push 分支後點綠色的 Compare & pull request。

審查時看什麼

審查不是找人的碴，是降低「合併後才爆」的機率。至少確認：

  • 變更範圍跟標題一致，沒有夾帶無關檔案。
  • 能在本機或 CI 重現通過。
  • 秘密（API 金鑰、密碼）沒有被 commit 進去。

審查者可在 diff 上留言，或用「建議變更」直接給出可一鍵套用的 patch。作者改完再 push，不必重開 PR。

建議先看的影片

官方用約四分鐘示範：開分支、commit、push、在網頁建立 PR。

Issues 與 Projects 的官方示範見下一支，完整清單在 官方影音。

相關資料