你是不是用著 GitHub，卻其實不太清楚自己在做什麼？
盲目操作只會把東西搞壞。
GitHub 上只有三個綠色按鈕。
按下它們之前，你只需要看一個地方。
這篇文章會用紅框標示出 GitHub 畫面上所有「該看」和「該按」的地方。
連線、提交、檢查 diff、合併、還原。
我們會用 10 張實際截圖，帶你跑完這整個流程。
打字交給 AI。
你只負責看和按。
遇到難懂的術語，我會順手用最簡單的方式解釋。
※ 本文中的 GitHub 畫面與規格以 2026 年 10 月的版本為準。畫面可能會隨時間改變。
第 1 章：連接 GitHub｜建立 Repository 並上傳本機紀錄
GitHub 的介面是英文的。
但要按的地方是固定的。
畫面上的紅框會告訴你該看哪裡、該按哪裡。
這一章裡，你只需要按一個綠色按鈕。
首先，建立一個 repository。
repository 就像一個置物櫃，用來在線上存放你的 Git 紀錄。
關於這個置物櫃裡裝了什麼，以及四個關鍵術語，我在上一篇文章中已經說明過了。
【附圖解】連國中生都看得懂的 Git 教學
https://x.com/dan_pro_man/status/2107224533099069671?s=20
就算你還沒看過那篇，光靠這篇文章也能跑完整個流程。
登入 GitHub，點選右上角的「+」圖示，選擇「New repository」。
直接開啟 https://github.com/new 也會進入同一個畫面。
你唯一需要填的就是名稱。
在「Repository name」輸入英數字組成的名稱。
例如「git-practice」就可以。
在「Choose visibility」下方選擇「Private」。
這代表不公開。
「Add README」的開關先保持關閉。
如果你已經有本機紀錄，建立一個空的 repository 再連線會比較輕鬆。
按下最下方的綠色「Create repository」按鈕。
按下後出現的畫面，是這一章最重要的部分。
靠近底部的地方有一個標題：「…or push an existing repository from the command line」。
下面的三行指令，就是我們今天會用到的。
上面的七行是給還沒有本機紀錄的人看的，你可以直接跳過。
這三行的意思如下：
第 1 行：告訴你的本機紀錄，這個置物櫃的地址在哪裡。
第 2 行：將主分支的名稱統一為「main」。
第 3 行：把 main 分支存進置物櫃。
從這個畫面複製地址（紅框處），用一行文字傳給 AI。
1把這個資料夾裡的紀錄上傳到 https://github.com/account-name/git-practice
Claude Code 會自己打出這三行指令。
Claude Code 是一個能根據指令在你電腦上執行任務的 AI。
在我的操作手冊裡，我規定它在 push 之前必須先跟我確認。
push 就是把本機紀錄存進置物櫃的操作。
所以它會在這裡先停下來。
回答「Yes」，然後重新整理瀏覽器畫面。
原本顯示三行指令的地方，現在會列出你的本機檔案。旁邊則是 commit message。
這就是「連線成功」的證明。
這裡有一件事希望你注意。
檔案列表上方的「main」字樣。
它代表你目前正在查看置物櫃裡的哪一個書籤。
書籤就是 branch（分支）。
它標記了你正在哪一欄堆疊紀錄。
接下來請不要直接去動這個「main」。
一開始我也沒太在意這件事。
結果直接在 main 上作業，浪費了很多時間才找到要退回哪裡。
連線失敗時，通常問題都出在地址。
結尾的「.git」漏掉了。
帳號名稱拼錯了。
如果看到「not found」，請回到圖②重新複製一次地址。
到這裡，你的本機紀錄就已經連上 GitHub 了。接下來是透過 Pull Request 進行合併的日常流程。
**
第 2 章：透過 Pull Request 合併｜提交 AI 的成果、檢查 diff，然後按下按鈕
從這裡開始進入日常流程。
Pull Request 就是一份寫著「請幫我合併」的提交申請。
這一章裡，你需要按三個綠色按鈕。
打字交給 AI。
你只負責看和按。
首先，傳一行指令給 AI。
1建立一個新分支，在 README 加上 3 行使用說明，commit 後上傳到 GitHub
README 是你第一個用來撰寫 repository 說明的檔案。
Claude Code 會建立分支。
修改檔案並 commit。
最後，它會在 push 之前停下來詢問你。
回答「Yes」，然後用瀏覽器打開置物櫃。
頂部會出現一條黃色橫幅。
它在通知你：「我剛剛把這個分支存進去了」。
按下右邊的綠色按鈕「Compare & pull request」。
這就是「提交」。
就像把草稿本交給老師一樣。
光是提交，並不會把任何內容寫進正式版。
必須經過審查才會真正合併。
提交畫面上有三個地方要看。
第一：最上方的箭頭。
「base: main」與「compare: work-branch」
這表示要從哪裡合併到哪裡。
只要確認左邊是 main 就好。
第二：「Add a title」裡的標題。
如果是 AI 產生的，裡面會包含變更摘要。
如果是手動提交，系統會預先填入 commit message。
手動提交時，用一行話寫清楚「做了什麼」。
第三：綠色的「Create pull request」按鈕。
按下去就代表受理這份提交。
提交之後，就需要人類接手了。
畫面頂部會出現四個分頁。
只看最右邊的「Files changed」分頁。
意思是已變更的檔案。
綠色的行是新增的內容。
紅色的行是刪除的內容。
這就是 diff。
如果你要求的那 3 行是綠色的，就算過關。
範例畫面中因為連同標題和空行一起加上了，所以總共有 6 行綠色。
如果出現你沒要求的紅色行，就不要合併。
範例畫面中有 1 行紅色。
「Items placed」裡少了一行備註。
如果你沒有要求這麼做，就在這裡停下來。
問 AI：「你為什麼刪掉這行紅色的？」
這是把工作交給 AI 時最關鍵的 30 秒。
以前光是看到審查通知就覺得壓力山大，我常常看都不看就直接按下去。
現在，我會先數紅色行有幾行。
只要有一行不是我要求的，我就會停下來。
如果 diff 沒問題，就回到「Conversation」分頁。
靠近底部有一個綠色的「Merge pull request」按鈕。
如果上方顯示「No conflicts with base branch」，就可以直接合併。
按下去後會變成「Confirm merge」。
再按一次。
這樣工作分支的紀錄就合併進 main 了。
顏色會變成紫色，並顯示「Merged」。
下方會出現一個方塊，寫著「Pull request successfully merged and closed」。
右邊則是「Delete branch」。
放心按下去吧。
消失的只是置物櫃裡工作分支的「書籤」。
既然紀錄已經合併進 main，就不會有任何東西遺失。
最後，更新你的本機環境。
告訴 AI：「切換到 main，並從 GitHub 拉取最新狀態」。
這樣就完成一次循環了。
下一個任務請從新的分支開始。
不要在 main 上直接作業。
到這裡，你已經完成了提交、檢查 diff、合併的流程。接下來要介紹 Revert，也就是合併後用來反悔的按鈕。
**
第 3 章：Revert｜一鍵撤銷合併後的錯誤
有時候合併之後才發現有錯。
在 Git 裡，你是「撤銷」已儲存的紀錄，而不是刪除它們。
GitHub 畫面上就有對應的按鈕。
叫做「Revert」。
重新打開你剛剛合併的那個 Pull Request。
裡面會有一行寫著「merged commit … into main」。
那一行的最右邊就是「Revert」。
按下去會發生什麼事？
紀錄並不會被刪除。
而是會建立一個帶有相反變更的新 Pull Request。
根據官方文件，當你合併這個新的 Pull Request 時，才算真正完成還原。
所以，revert 走的也是第 2 章的同一套流程。
檢查 diff，然後按綠色按鈕。
不是刪除，而是新增一筆「已還原」的紀錄。
如果要叫 AI 處理，就說：「撤銷我剛剛合併的 Pull Request」。
Claude Code 會用 git revert 做一樣的事。
還有一個畫面你也可能會遇到。
「This branch has conflicts that must be resolved」。
這就是衝突（conflict）。
當 main 和工作分支對同一行做了不同修改時就會發生。
綠色按鈕會變灰，無法點擊。
不要試圖在畫面上解決它，直接傳一行指令給 AI。
1拉取 main，並把衝突部分的兩個版本都秀給我看
由你決定要保留哪一個。
等 AI 修正並重新上傳後，綠色按鈕就會恢復。
衝突不是失敗。
它只是揭露了「同一行被改了兩次」這個事實。
最後，有一件畫面上看不到的事。
金鑰。
含有密碼或 API key 的檔案，絕對不能上傳到 GitHub。
就算你用了 Revert，一旦金鑰被上傳，就視為已洩漏，必須重新產生。
上傳前，先告訴 AI：「把 .env 排除在紀錄之外」。
在我自己的工作環境裡，我會把 AWS 設定寫在文字檔中，並遵循同樣的流程。
沒檢查 diff 就合併的設定，會直接跑在正式環境上。
因此，按下按鈕前那關鍵的 30 秒，我絕不交給 AI。
畫面上的所有按鈕都由人類來按。
即使我不斷擴大 AI 的工作範圍，這條規則也從未改變。
到這裡，連線、提交、合併、還原的完整流程就全部結束了。
最後，我準備了可以直接使用的素材。
我把在 GitHub 畫面上完成一次循環的步驟都寫出來了。
也將本文中的畫面與 prompt 整理成可直接套用的格式。
- GitHub 畫面對照海報（9 張畫面、69 個術語）
- AI 搞砸時的復原地圖（6 種情境）
- 完成一次循環的 7 組 Prompt
- 合併前檢查清單（8 個項目）
以上整合成一本 15 頁的 PDF 小冊子提供。
只要有這些，你今天就能開始跑循環。
想領取的話，只要加入下方的 Open Chat。
加入後依照指示傳送「Submit」，就會自動發送給你。
https://line.me/ti/g2/pEpZQdEyn1BM5Zi2wqLBT2rZYpC0ZaOncIWTag
總結：今天就先跑完一次循環
不要把 AI 的成果直接放進 main。
從工作分支提交、檢查 diff，然後按下綠色按鈕。
一次循環裡總共要按三個綠色按鈕。
我第一次親手按下 Revert 的那天，才明白紀錄是不會被刪除的。
從那之後，我就不怕動手嘗試了。
你不需要一次把所有事情做完。
今天，只要做一件事就好。
打開第 1 章建立的 repository，傳一行指令給 AI。
建立一個新分支，在 README 加上 1 行內容，然後上傳到 GitHub
黃色橫幅出現時，按下綠色按鈕，打開「Files changed」。
如果只有一行綠色，就算過關。
合併之前，用自己的眼睛確認那一行。
這就是擴大你能交給 AI 處理範圍的第一步。
對於 30 歲以上的工程師來說，致勝關鍵不在工作量，而在於設計。
與其每次工具更新就重學一遍，不如先定義好「在哪裡踩煞車」還比較快。
AWS 和 AI 的演進速度非常快。
去看別人在實際工作中測試留下的 log，比自己一個人苦苦追趕快得多。
在我的 AI × 工程實踐中，我不只留下成功的紀錄，也會把搞砸的、被排除的紀錄一起留下來。
歡迎追蹤我，別錯過未來的實戰心得！@dan_pro_man
