一個人的 commit，不足以應付兩條開發路線

昨天的流程停在本機：修改、檢查差異、git commit。這套流程只保證一件事——自己的版本紀錄是完整的。它沒有回答另一個問題：當專案同時被兩個人修改，誰的版本才是大家接下來要接續的基準？

這個問題不限於團隊。同時開兩個 AI Agent 處理不同任務、或在兩台機器上開發同一個專案，都會出現同樣的狀況：兩份修改從同一個版本分岔出去，各自往前走，最後必須合併成一個版本。Git 處理這件事的方式是三組操作：用 branch 隔離各自的進度，用遠端儲存庫（remote repository）交換提交，用 merge 或 rebase 把分岔的歷史整合起來。

以下沿用昨天的 todo.md 範例，假設專案已經放在 GitHub 上。建立 GitHub 儲存庫的步驟請參考官方說明，本篇重點放在指令與判斷依據。

遠端儲存庫：origin 與 origin/main

多人開發需要一個共同存取的儲存庫。每個人在本機保有完整的版本紀錄，完成修改後推送到遠端，需要別人的成果時再取回。

git clone https://github.com/OWNER/team-practice.git
cd team-practice

git clone 會取得整個版本紀錄，並自動設定名為 origin 的遠端。之後有三個名稱要分清楚：

• main：你本機的 branch，git commit 只會更新它。
• origin：遠端儲存庫的簡稱，指向 GitHub 上那份儲存庫。
• origin/main：本機記錄的、上次連線時看到的遠端 main。它不會自動更新，執行 git fetch 或 git pull 之後才會跟著改變。

origin/main 經常被誤解成「遠端現在的狀態」。它其實是一份快取；你在本機看到的遠端進度，只新到你上次取得更新的那一刻。Git 官方文件：git remote

branch：讓未完成的修改不影響共用版本

直接在 main 上開發，會讓做到一半的修改和大家共用的版本混在一起。branch 的作用是替一條開發路線建立獨立的提交序列。

git checkout -b feature/todo-deadline

git checkout -b 建立新的 branch 並切換過去，新的 branch 從目前所在的提交延伸。Git 官方文件：git checkout

git checkout 同時負責切換 branch 與還原檔案兩種用途。Git 2.23 之後把切換 branch 的功能獨立成 git switch，本篇的 git checkout -b 對應 git switch -c，兩者目前都可使用。Git 官方文件：git switch

在這個 branch 上修改 todo.md，加入截止日期欄位：

# 待辦事項

- [ ] 撰寫 Day6 草稿（截止：9/19）

照昨天的流程檢查並提交，再把 branch 推送到遠端：

git add todo.md
git commit -m "待辦事項加上截止日期"
git push -u origin feature/todo-deadline

-u 會把本機 branch 與 origin/feature/todo-deadline 建立追蹤關係，之後在這個 branch 上直接執行 git push 即可。推送 branch 不會動到遠端的 main；多數團隊會在 GitHub 上開 Pull Request，經過審查後才併入 main。GitHub 官方說明：Pull Request

取得更新：fetch 與 pull 的差別

假設這段期間同事完成了另一項修改，並已併入遠端 main。你的本機還不知道這件事，因為 origin/main 尚未更新。

git fetch origin

fetch 只做一件事：把遠端的提交下載到本機、更新 origin/main 這類 remote-tracking branch。它不會修改你的工作目錄，也不會動到目前的 branch。Git 官方文件：git fetch

git pull 則是 fetch 加上整合，預設會在取得更新後直接 merge 到目前的 branch。差別在於中間少了檢查的機會。先 fetch，就能在整合前確認雙方各改了什麼：

git log --oneline --left-right HEAD...origin/main
git diff HEAD...origin/main

第一個指令列出兩邊從共同起點之後各自新增的提交，< 標記的是你的提交，> 是遠端的。第二個指令中的三個點代表「從共同起點到 origin/main」，也就是同事單方面改了什麼，不會把你自己的修改一起算進差異裡。反過來看自己的修改則是 git diff origin/main...HEAD。

這個區別在整合時很重要。如果直接比較兩個最終版本（git diff HEAD origin/main，兩個點），對方新增的內容會顯示成你這邊的「刪除」，很容易誤判成有人移除了功能。Git 官方文件：git diff

整合分岔的歷史：merge 與 rebase

確認差異後，要把同事已併入 main 的修改納入自己的 branch。有兩種做法。

merge 會建立一個新的提交，把兩條歷史接在一起：

git merge origin/main

原本的提交都保持不變，歷史中會留下分岔與合併的形狀。這是共用 branch 的預設選擇，因為它不改寫任何已經存在的提交。Git 官方文件：git merge

rebase 則是把自己的提交拆下來，重新套用到 origin/main 之上：

git rebase origin/main

結果是一條直線歷史，看起來像是你一開始就從最新版本出發。代價是被重新套用的提交會產生新的識別碼——原本的提交被取代了，不是被移動。因此有一條界線：只對尚未分享、或確定沒有其他人接續開發的提交使用 rebase。已經推送並被他人拉取的提交若被改寫，對方的歷史會與遠端對不上。Git 官方說明：Rebase 的注意事項

實務上的常見安排是：自己的 feature branch 在推送前用 rebase 保持整齊，共用 branch 之間的整合用 merge。團隊若已有約定，依約定執行即可。

執行前先確認工作目錄乾淨（git status）。有未提交的修改時，merge 與 rebase 可能拒絕執行，或讓整合狀態更難判讀。

處理 conflict：Git 停下來要你決定

當兩邊修改了同一個檔案的同一段內容，Git 無法判斷哪個結果正確，就會停止整合並標記衝突：

git status

預期會看到檔案列在 Unmerged paths 中。開啟 todo.md，會看到 Git 插入的標記：

<<<<<<< HEAD
- [ ] 撰寫 Day6 草稿，補上 GitHub 操作
=======
- [ ] 撰寫 Day6 草稿（截止：9/19）
>>>>>>> 待辦事項加上截止日期

HEAD 那一側是整合的基準，>>>>>>> 那一側是正在被套用的修改。在 rebase 中，這兩側的意義與直覺相反：因為 Git 是把你的提交套用到 origin/main 上，所以 HEAD 是同事的版本，下半部才是你的修改。merge 時則相反，HEAD 是你目前 branch 的內容。弄錯方向就可能保留錯誤的一側。

解決衝突的步驟是：編輯檔案成為整合後應有的內容、刪除三行標記、確認結果，然後告訴 Git 這個檔案處理完了：

git add todo.md
git rebase --continue

如果用的是 merge，對應的是 git merge --continue。兩者都不需要另外執行 git commit，提交由整合流程建立。

git add 在這裡的意義是「宣告衝突已解決」。Git 不會檢查內容是否正確，也不會檢查標記是否刪乾淨——把 <<<<<<< 一起提交進去是真實會發生的錯誤，提交前應該用 git diff --cached 檢查一次。

若判斷不了該怎麼整合，可以退回整合前的狀態：

git rebase --abort   # merge 時用 git merge --abort

這會撤銷整合過程中的修改，回到執行整合前的 branch 狀態。

讓 AI 協助整合

整合工作中，「讀懂雙方改了什麼」佔掉大部分時間，而這正是 AI 能有效協助的部分。以下指示假設使用具備檔案讀取與指令執行能力的 AI Agent，實際的 branch 與檔案名稱依專案調整。

• 整理雙方差異：「先執行 git fetch origin，再以共同起點分別比較我的 branch 與 origin/main 各自新增了哪些提交與修改。說明兩邊改動的檔案與目的，指出可能互相影響的地方。先回報，不要修改檔案。」明確要求「以共同起點分別比較」，可以避免前面提到的方向誤判。

• 提供整合依據：「這次整合需要同時保留截止日期欄位與 GitHub 操作事項。請依此解決 todo.md 的衝突，移除衝突標記後回報整合結果。」衝突的本質是需求層級的取捨，Git 判斷不了，AI 也猜不到。指示中必須說明整合後應有的行為，而不是只說「解決衝突」。

• 檢查整合結果：「請回報目前 Git 狀態、這次整合後 HEAD 相對於 origin/main 的差異，以及是否仍有衝突標記殘留。」

需要注意的是，Git 沒有標示衝突，不代表整合正確。Git 比對的是文字，不是行為。同事改了後端的回傳格式、你改了前端的讀取邏輯，兩邊檔案不同，Git 會順利合併，程式卻會在執行時出錯。這類問題只有實際執行或跑測試才看得到，因此整合後要請 AI 執行既有測試並回報結果，不能只看它的差異摘要。

整合完成、確認行為無誤後，再推送分享：

git push

若 rebase 改寫了已推送的 feature branch，這次 push 會被拒絕。此時要確認那條 branch 確實只有自己在用，再依團隊約定處理；直接強制推送會覆蓋遠端紀錄，是會造成他人修改遺失的操作。

Git 保證的是版本紀錄不遺失，不是整合結果符合需求。 哪些修改該保留、整合後的行為是否正確，仍然由我們決定並驗證。