十分鐘學會正確的 GitHub 工作流（YouTube 教程）
後設資料
- URL：https://www.youtube.com/watch?v=uj8hjLyEBmU
- 媒體：YouTube 影片（口述教學 + 畫面演示）
- 語言：中文（敘述時混用「視頻 / 倉庫」等大陸用語，影片受眾跨繁簡兩岸）
- 作者：未明示（頻道未在轉錄中署名）
- 發表日：未明示
- 內容形式：純口述 + 畫面示範，本頁保留逐字稿轉文字版本作為長期保存
一句話濃縮
「建分支 → 改 → diff → add → commit → push → PR → squash-merge → 清理本地與遠端分支 才是給開源作者與成熟專案用的正確流程」——直接
add / commit / push主分支「一把梭」會讓任何有點成熟度的專案管理崩潰；這套流程不是繁瑣，是把「個人改動」與「專案歷史」兩個角色明確分開的工程紀律。
提取要點
- 三層心智模型（給新手）：(1) Remote（GitHub 上的共享遠端倉庫）/ (2) Local Git（本地 Git 倉庫，保存你告訴 Git 的所有資訊）/ (3) Disk（磁盤上原始檔的真實樣子，編輯器看到的）；理解三層分離才能解釋「我改了檔案但 Git 不知道」「我 commit 了但 GitHub 沒變」「checkout 之後 disk 自動同步成那個 branch 的樣子」這些日常困惑。
- Feature Branch 而非主分支直推：clone 後第一件事是
git checkout -b myfeature，理由：(a) 不會把主分支搞壞；(b) 多人合作互不干擾；(c) 是 git 的「正確使用方式」。直推 main 在「任何一點點成熟度」的專案都不可能。 - 七步流程（標準 happy path）：
git clone <url>— Remote 複製到 Local Git + Disk 都同步git checkout -b myfeature— 從當前 branch 複製出新 feature branch- 改檔案 →
git diff看 disk 與 Git 紀錄的差異（強烈建議在下一步前先 diff） git add <files>— 把要 commit 的檔案放進暫存區（告訴 Git「這些我想 commit」）git commit— 真正寫入 Local Git，多出一個 commitgit push origin myfeature— Local Git 的 branch 推到 Remote，GitHub 上多出 myfeature branch- 在 GitHub 介面建立 PR，請求把 myfeature 的改動 pull 進 main
- 同步 main 到 feature（main 在你開發中又有更新）：
git checkout main— 切回 main，disk 變回 init 狀態git pull origin main— 把遠端 main 同步到本地 main + diskgit checkout myfeature— 切回 featuregit rebase main— 把你的 commit 先扔旁邊 → 套上最新 main → 再把你的 commit 接回去；衝突時手動選代碼git push origin myfeature -f— rebase 改寫了歷史，必須-f（force）才能推回
- Rebase 而非 Merge 的好處：rebase 後你的修改像是「在最新的 main 上新做的」，commit 歷史保持線性、乾淨；merge 會留下分叉與 merge commit。
- Pull Request 的命名邏輯：形式上主分支屬於專案 / feature branch 屬於個人——即使是同一個人，這兩個分支扮演不同角色；PR = 「請項目主人把我這個分支的改動 pull 進專案」。
- Squash and Merge（PR 合併的標準選擇）：feature branch 的 commit 通常很亂（格式調整 / bug fix / 多次嘗試），不希望污染 main commit history。Squash 把 feature branch 所有 commit 合併成一個 commit 進 main——目標是 main 上每個 commit 都是正常工作的。
- PR 合併後的清理：(a) GitHub 上「Delete branch」按鈕刪遠端分支；(b) 本地
git checkout main→git branch -d myfeature刪本地分支；(c)git pull origin main把剛剛被 squash 進的 update 同步到本地。完成後 Local Git / Disk / Remote 三者再次一致。 - 這流程的合法性是「看起來麻煩，實則必須」：「
add commit push一把梭」在任何有一點點成熟度的專案會讓專案管理崩潰；個人專案 / 開源專案 / 公司專案都用這套——學會它、適應它，是程式生涯的長期投資。
提取概念
連結到此來源衍生 / 更新的 wiki 頁：
- GitHub工作流（新建 — concept umbrella；本來源是 vault 中第一份 git/GitHub 工作流主軸來源；含七步 happy path + rebase 同步流 + squash-merge + 清理三步等完整流程）
- Pull-Request（新建 — concept；命名邏輯（主分支屬專案 / feature branch 屬個人）+ squash-merge 為何是預設選擇 + 為什麼是「機構化的 code review 介面」）
- Git（新建 — entity / product；Linus Torvalds 2005 distributed VCS；本來源是 vault 第一份明確處理 Git 命令層的來源）
- GitHub（新建 — entity / product；最大公開 git 託管平台；2008 創立 / 2018 被 Microsoft 收購；PR / Issues / Actions 等社交化協作介面是 git 之上的關鍵價值層）
- AI輔助開發（補入「版本控制紀律是 AI 輔助開發的前置條件」段——AI agent 大量產出代碼時，feature branch 隔離 + diff 檢查 + PR review 是控制 AI 過度設計、技術債累積的工程化前置動作；對位 Claude-Code 教程「Hooks 自動清技術債」與「自動 PR review」企業級用例）
- Claude-Code（補入「git/GitHub 工作流是 Claude Code 企業級用例的執行底層」段——自動 PR review / GitHub MCP / 自動文件更新都建立在這套標準工作流之上）
- 程式碼風格指南（補入「PR 是 style guide 的最後一道把關」段——再短的 style guide 也需要在 PR review 時被人或 hook 確認；squash-merge 確保 main 上每個 commit 都通過了風格驗收）
原文（逐字稿轉文字版本）
YouTube 影片可能下架或變更標題，本頁保留 ingest 當下的口述逐字稿；保留原口語節奏與用詞，未做大幅改寫。
開場：定位
今天給大家帶來的是一個 GitHub 工作流的極簡教程。我們只介紹一種最常用、最好用的使用 GitHub 工作的方法——無論你是維護自己的項目，還是參與開源項目，掌握這一套流程就足夠了。沒有廢話，沒有理論，全是應用，讓我們開始吧。
場景設定：Remote / Local Git / Disk 三層
我們假設在 GitHub 上面有一個倉庫（Repository），它可能是你自己的，也可能是別人的。然後這個 Repository 的主分支是 main（當然原來叫 master）。我們假設這個 main branch 上面只有一個 commit 是 init（實際上有若干個也無所謂——它現在有多少 commit 是無關的）。
那我們管這個所有人都共享的、遠端的代碼倉庫（也就是 GitHub）叫做 Remote。
當我們想修改或者貢獻代碼的時候，第一件事就是要把 Remote 的倉庫複製到本地。我們可以通過 git clone 命令在本地複製一個一模一樣的倉庫。
這裡注意，我們最好把本地想象成兩個部分，這樣對新手來說更容易理解：
- 第一個我們叫做 Local Git——你可以把它想象成一個本地的 Git 倉庫，這裡面擁有所有你告訴 Git 的信息。
- 另一個部分我們叫做 Disk（磁盤）——這個部分是我們的原文件真正在磁盤裡的樣子，也是我們用編輯器（比如 VSCode）打開這個原文件的時候它的狀態。
在我們剛進行完 clone 這個操作之後，Remote、Local Git 和 Disk 都是一樣的。
建立 Feature Branch
在我們要修改代碼的時候，第一件事就是建立一個新的 Feature Branch。建立 Feature Branch 而不是直接往 main 上面 push 代碼有很多好處：(a) 它不會把你的主分支搞得不能工作；(b) 它非常有利於多人合作。所以我們認為這是使用 Git 最正確的方式。
建立 Feature Branch 的方法就是在你 clone 之後使用 git checkout -b myfeature，這個 myfeature 就是你 Feature Branch 的名字。這個命令會複製一份你當前的 Branch 到你的新 Branch 上。在我們 clone 之後，當前的 Branch 或者說當前的 Checkout 是 main，所以我們相當於複製了一份這個 main Branch 到 myfeature 上。
於是現在在我們的 Local Git 裡面，有 main Branch 和 myfeature Branch 這兩個 Branch 是一樣的。Disk 也改成了 myfeature——這只是幫助大家理解的，實際上我們的硬盤對這個原文件來自於哪個 Branch 一無所知，它只知道這個原文件長成什麼樣子。所以現在不管是 main Branch 還是 myfeature Branch，它們的原文件長得一樣，硬盤並不在乎你現在是在哪個 Branch。
當你使用 checkout 命令之後，Git 會把這個 Branch 上的所有原文件同步給硬盤——硬盤裡面保存的原代碼就會是這個 Branch 裡面的代碼。
修改 / Diff / Add / Commit / Push
接下來我們就可以修改代碼了，不管你是修 Bug 還是加 Feature。當你改好代碼保存文件之後，你的硬盤上面的文件是有變化的，但是 Git 對此一無所知。
這個時候你可以使用 git diff 命令來看：我現在硬盤上的這個改變，跟我 Git 保存的分支有什麼區別。我強烈建議大家在做下一步的操作之前先用 git diff 看一下自己到底做了什麼改變。
當我們決定把修改的文件告知 Git 的時候，我們可以使用 git add 命令——git add 命令的參數就是文件名。你可以把所有想要告知 Git 你修改了的文件加到 git add 命令後面。這個命令會把這些文件放到一個叫做暫存區的地方。暫存區是什麼意思你不用理解，你只需要知道 Git 現在知道了：你有一些代碼想要 commit。
在你用 git add 添加了所有你想修改的文件之後，可以使用 git commit 來把這些修改真正的放到 Git 裡。在使用 git commit 命令之後，我們的 Local Git 就會新增一個 commit。我們可以看到現在我的 feature branch 跟這個 main branch 已經不一樣了。同樣的為了幫助理解，我們把 disk 的部分也更新成了 myfeature 的樣子。但是大家要知道實際上 disk 是沒有改變的——這個 commit 裡面就是我們剛才做的代碼改動，我們只是把這些代碼改動告知了我們的 Local Git，放到了我們的 Local Git 裡。
那到現在為止 GitHub 還什麼都不知道。我們需要把這個 Local Git 的變化告知 GitHub，這個時候我們就用 push 命令：git push origin myfeature。在使用了這個命令之後，你就會發現你的 GitHub 多出來了一個 branch 是 myfeature，這個 branch 裡面保存著你代碼的改動。
同步 main 的更新（Rebase）
我們非常常見的情況是，在我們修改代碼的時候 main branch 又有更新了。比如說當我們 push 到 myfeature 這個 branch 之後，我們發現 main branch 又多了 update 這個 commit。那我們可能要測試一下：我的這個 feature 在新的 update 更新之下是不是還好使。所以我們要把 main branch 的更新給同步到 myfeature 這個 branch 裡。
那為了做這件事，我們首先要更新我們的 local branch。因為我們可以看到，當前我們 Local Git 裡的 main 跟 Remote 的 main 是不一樣的。
所以首先我們要切換到 main 這個 branch 裡面，我們使用 git checkout main。這個時候我們硬盤裡的原代碼就是 init 的狀態，而不是我們剛才修改過的狀態了。
在 checkout 之後，我們運行 git pull origin main。這行代碼的意思就是：把遠端的 main 給同步到我 local 的 main 裡。在這個操作之後，遠端 GitHub 上新的 update 這個 commit 就會被同步到我的 Local Git 和我的 disk 上。這個時候我的 Local Git 和我的 disk 就和遠端的 GitHub 一樣了。
然後我們要回到 feature branch：git checkout myfeature。那當前狀態的原代碼就是由我們修改的那個 fcommit 的變化，但是沒有遠端的 update 這個變化的代碼。
那為了要同步這個 main 的代碼改變，我們使用 git rebase main。git rebase main 的意思是：把我的修改先都扔到一邊，然後把 main 最新的修改拿過來，接著在這個最新修改的基礎之上，再把我的這個 commit 給嘗試弄回去。那在這個過程中有可能會有 rebase conflict，那如果出現了 rebase conflict 就需要你手動的去選擇你到底要哪一段代碼。
在 rebase 成功之後，我們的 feature branch 就變成了現在這個樣子：init → update → fcommit。我們可以看到在 rebase 成功之後，我們相當於是在最新的 main branch 上面做了我們的修改。這也是使用 rebase 而不是 merge 的好處。
那在更新完我們的 feature branch 之後，我們需要 git push origin myfeature 把我們 Local Git 裡面的這個 branch push 到 GitHub 上。但是注意，由於我們做了這個 rebase，所以我們在 push 的時候必須要加上這個 -f——這個 -f 表示 force，強行 push。
Pull Request 與 Squash and Merge
到此一切準備就緒，我們就要把我們更新的代碼合併到這個 main branch 裡了。這個過程我們叫做 Pull Request。
為什麼叫 pull request 呢？因為我們形式上認為這個主分支是屬於項目的，不屬於任何個人；而功能分支（也就是所謂的 feature branch）是屬於個人的。儘管這個 feature branch 的主人和這個項目的主人可能是一個人，但在這兩個分支上他們是不同的角色。Pull Request 的意思是：request 這個項目的主人把我這個新的分支的改變給 pull 到這個項目裡去——所以叫 pull request。
在 GitHub 上面你可以非常方便的建立 pull request，要求這個 main branch 把你的 myfeature branch 上面的改動給 pull 進去。在這個 main branch 的維護者（當然有時候有可能是你自己）審查了你的代碼之後，一般情況下會用 squash and merge。
為什麼要做這個 squash 操作？在我們這個例子裡，myfeature 這個 branch 只有一個 commit，但是在更多的情況下，我們的功能分支上面的 commit 是比較亂的——有可能有很多代碼格式的改變、有很多 bug fix。我們不希望把這些 commit 每一個都放到我們的 main branch 裡面，我們希望我們 main branch commit history 儘可能的簡潔，尤其我們希望我們的 main branch 裡面每一個 commit 都是正常工作的。
所以在大多數情況下面對 pull request 我們會選擇 squash and merge。Squash and merge 的意思就是：把這一個分支上面的所有改變合併成一個改變，然後把這個 commit 給放到我的 main branch 上——也就是這些改變可能變成了 update2 這個 commit，你的代碼改動都被正常的合併到了 main branch 裡面，只是 commit 的結構、數量和名字改變了。
合併後的清理
那在 pull request 被 merge 之後，一般情況下我們就會把遠端的這個 branch 直接刪掉——在 GitHub 上有一個按鈕叫 Delete branch。
當然這個時候還沒完。遠端的那個 myfeature 被刪掉了，但是我們的 Local Git 上還有。這個時候我們首先要切換到 main branch 上：git checkout main，然後使用 git branch -d myfeature 來把這個 myfeature branch 從 Local Git 裡面也刪掉。
最後在 main branch 裡面，我們再使用一次 git pull origin main，把最新的這個更新給拉到我的 local 的 main branch 和我的 disk 上。我們看在經過了這些操作之後，我們的 Local Git、我們的 disk 就又和我們的 Remote GitHub 一模一樣了。
結語：為什麼學這個
那麼我今天介紹這個 GitHub 工作流呢，和很多人平時可能使用的 add commit push add commit push 這種一把梭的方法比起來還是稍顯麻煩。然而在任何一個有一點點成熟度的項目裡，都不可能讓所有的程序員都在那 add commit push 一把梭——這種工作流程會讓你的項目管理崩潰的。
而我們今天講的這套 GitHub 工作流，不光是在個人項目上使用，在很多的開源項目上、甚至於公司的項目裡，他們都會使用這一套流程。所以學會它、適應它、使用它，對你未來的編程生涯絕對是有好處的。