排到一個 PR 要 review，改動是一段限制檢查的邏輯。網頁上的 diff 看起來沒問題，三行判斷式，邏輯很直覺。但這段判斷牽涉到一個外部 API 的非同步呼叫，光看文字很難確定判斷式擺的位置對不對——會不會在回呼還沒結束前就先放行了。
想在本機跑起來測，才發現 Node 版本跟手上的不一樣、.env 沒有、資料庫是空的。切過去看 PR 又會動到自己還沒 commit 的東西。半小時過去，PR 還沒真的開始看，時間全花在把環境弄起來。
這篇要處理的是反過來的順序：先把 Mac 設定好，讓每次收到 review 邀請，幾分鐘內就能把 PR 實際跑起來看，而不是每次重新來一次環境設定。
先裝 GitHub CLI，PR 才不是只能在網頁上看
brew install gh
gh auth login
gh auth login 會走瀏覽器登入，選 HTTPS 或 SSH 都可以，跟你原本 clone repo 用的方式一致就好。裝好之後，PR 不再只是網頁上一份唯讀的 diff，而是可以直接在終端機操作的物件：
gh pr view 123 --web # 開瀏覽器看這個 PR
gh pr diff 123 # 直接在終端機看 diff，不用開瀏覽器
gh pr checkout 123 # 把 PR 拉成本地分支，切過去
gh pr checkout 背後做的事，其實是 git fetch origin pull/123/head:pr-123 再切過去——GitHub 對每個 PR 都開了一個 pull/<number>/head 的參照，gh 只是幫你省了記這串路徑的麻煩。
用 worktree 拉 PR，不動手上的工作
gh pr checkout 預設會切換你目前的工作目錄，如果手上還有沒 commit 的東西，一樣得先 stash。前一篇提過的 worktree，這裡正好用得上：
git fetch origin pull/123/head:pr-123
git worktree add ../pr-123 pr-123
pr-123/ 是一個完全獨立的資料夾，cd 進去就能跑，不影響手上還在寫的功能。同時收到兩、三個 review 邀請，就開兩、三個 worktree，各自跑各自的 docker compose、各自的 dev server，看完一個就 git worktree remove 掉，不用排隊等前一個看完才能切下一個。
讓 PR 真的跑得起來：環境相依要先準備好
worktree 共用的只有 .git，工作目錄裡沒進版控的東西——node_modules、.env、資料庫——每個資料夾都要自己準備。這幾樣先在 Mac 上裝好，才不會每次都卡在同一個地方：
Node 版本管理。 PR 改動的分支可能鎖了跟你手上不同的 Node 版本。用 nvm（或 volta、fnm）裝好，配合專案裡的 .nvmrc：
brew install nvm
cd pr-123 && nvm use
環境變數。 專案通常會留一份 .env.example，每個新開的 worktree 都複製一份改成 .env：
cp .env.example .env
本地依賴服務。 資料庫、Redis 這類，用 docker compose 起一份給 review 用的，不要接測試環境或正式環境的資料庫——PR 裡的改動如果有問題，你不會想在正式資料庫上第一次發現。
docker compose up -d db redis
三樣都備好，pr-123/ 才是一個真的能跑的環境，送一筆超過上限的請求進去，才看得出那三行判斷式擺對了沒有，而不是憑 diff 的文字猜。
SourceTree 要多做的一步
SourceTree 不認得「PR」這個概念——它是 GitHub 伺服器端的物件，不是 git 原生的分支。要在 SourceTree 裡像操作一般分支一樣切換、看 log，得先用 gh 或 git fetch 把它變成本地分支：
git fetch origin pull/123/head:pr-123
跑完這行，pr-123 就會出現在 SourceTree 左側的分支清單裡，之後 checkout、看 log、跟其他分支比較，都跟平常操作一樣。
gh 指令一覽，留言跟核准也不用開瀏覽器
看完環境沒問題，要留意見或核准，一樣可以留在終端機：
gh pr comment 123 --body "限制檢查要放在外部 API 回呼結束之後，目前這個位置有 race condition"
gh pr review 123 --request-changes --body "見留言"
gh pr review 123 --approve
--request-changes 會擋掉合併按鈕，--approve 才會放行，跟網頁上的行為一致。習慣用終端機的人，整個 review 流程——checkout、跑、留言、核准——可以完全不用切到瀏覽器。
環境備好，才有餘力看真正的問題
這篇沒有講怎麼判斷 PR 裡的邏輯對不對，講的是更前面一步：讓「把 PR 跑起來看」這件事，成本低到你會願意每次都做。gh 負責把 PR 變成本地看得到、操作得到的分支，worktree 負責讓這件事不干擾手上的工作，.nvmrc、.env.example、docker compose 負責讓環境真的跑得起來。
這幾樣都是一次性的設定，裝好之後每個 PR 重複用。下一篇會接著講，環境備好、PR 也跑得起來之後，怎麼請 AI 幫忙看出人工容易漏掉的地方。