先選好提交與分支對比，再審查改動

審查之前，先想清楚要回答什麼問題。「這個提交改了什麼」和「這個分支從分叉以來改了什麼」，即使涉及同樣的分支名，得到的 diff 也可能不同。

想先了解它是否適合你的任務？檢視 Mac Git 差異檢視器的用途與限制，再按下面的步驟開啟對比。

開啟對比

以審查 feature 相對 main 的改動為例，操作時換成你自己的分支名：

開啟本機 Git 儲存庫，點選檔案欄中的Compare Versions…。
從Commit切換到Compare。
在From（base）一欄選擇Local branches，選中 main；在To（head）一欄選擇Local branches，選中 feature。兩欄各有自己的分支來源和搜尋框。
想看 feature 從分叉後做的工作，選Since the branches split；想比較兩個分支目前的內容，選Direct comparison。下一節會解釋結果為什麼不同。
核對底部摘要裡的分支名和短提交 ID。方向選反了就點Swap，確認後點View Changes。
在變更檔案樹裡選一個檔案，檢視行內 diff。

如果要以 origin/main 為基準，在舊版本一欄改選Remote branches。這裡列的是本機儲存庫已有的遠端跟蹤引用，不會實時查詢伺服器。需要遠端的新提交時，先用平時的 Git 客戶端更新儲存庫，再重新開啟版本選擇視窗。

Yenpo 會把對比固定到具體的提交上。分支之後再往前走，正在審查的提交也不會變。要審查分支上新的提交，就新建一個對比。

以下面這段歷史為例：

      M1──M2  main
     /
O───X
     \
      F1──F2  feature

直接比較 main → feature，比的是 M2 和 F2，兩邊各自做的改動都會混進來。Since the branches split比的是 X 和 F2，通常更適合回答「feature 分支加了什麼」。它不會模擬最終的合併結果，也不能告訴你合併時會不會衝突。

審查 merge commit 時，Commit模式只和第一個父提交比較。這只是看合併的一種角度，不會分別和每個父提交比較，所以先確認它正好回答你的問題。

把滑鼠停在變更檔案樹上方的版本資訊上，可以看到完整提交 ID。Direct comparison顯示的是選中的舊版本和新版本；Since the branches split的基準標記為 merge-base(...)，對應共同祖先的 ID，而不是舊版本分支的最新提交。

也可以在同一個儲存庫的終端中執行下面兩條唯讀命令，核對相同的版本。先把 BASE_COMMIT_OID 和 HEAD_COMMIT_OID 換成 Yenpo 中顯示的兩個完整 ID：

git show --no-patch --format='%h %s' BASE_COMMIT_OID HEAD_COMMIT_OID
git diff --stat BASE_COMMIT_OID HEAD_COMMIT_OID --

第一條確認兩個提交，第二條彙總這兩個已提交版本之間的檔案差異；目前未提交的修改不在這個範圍裡。複查之前的審查時要用當時的 ID，分支名現在可能已經指向新提交。

在變更檔案樹裡點開檔案，會開啟唯讀的行內 diff。對比中的檔案可以和目前檔案同時開啟，所以分析呼叫方或測試之前，先確認每個標籤頁顯示的是哪個版本。你的專案裡可能已經有選中的 head 裡沒有的改動。

對每一處會影響行為的修改，多讀幾步：

一個叫「處理併發讀取」的測試，可能只是先後呼叫了兩次。要看它的準備步驟和斷言，別隻看名字。Promise 快取審查裡有具體例子。

點選對比欄中的Ask AI to review this comparison按鈕。它會準備一份已附加目前對比的草稿，還不會傳送請求。先核對對比標籤，再按自己的審查重點修改草稿，確認後傳送。尚未連線模型的話，先按連線模型服務商完成設定。

例如：

檢查這次改動有沒有引入取消和錯誤處理方面的回歸。每個發現都請給出改動位置、觸發它的狀態、使用者會看到什麼，以及支撐結論的程式碼。基線裡原來就有的問題請單獨列出。

逐條確認它給出的觸發條件在選中的提交裡真的會發生。唯讀程式碼判斷不了執行順序時，讓它給出重現步驟或針對性的測試，再自己執行。回答裡的測試並沒有跑過。

Git 對比對話始終唯讀。要修復，就針對目前專案另開一個普通對話，開啟Allow Edits。對比可以留著作參考。

改完後，檢視專案 diff，自己執行專案的檢查。停止執行不會撤銷已經寫入的檔案。如果專案原本就有別的改動，決定提交哪些之前，先把它們和這次修復分開。