GitHub PR 隱藏空白後，為什麼變更看起來變少了
只改了一點邏輯，格式化工具卻調整整個檔案的縮排，滿版紅綠很容易淹沒關鍵變更。GitHub 10月22日公布的改善減少了一個重複動作：個人的空白顯示偏好現在可以跨提取要求儲存。
下一份 PR 也沿用這次選擇
在 Files changed → Settings → Whitespace changes 中，可選 Always show、Always hide 或 Hide for this diff only。儲存的偏好屬於個人，跨 PR 生效。隱藏時，All commits 旁會出現 Hide whitespace；點 X 可暫時顯示空白，而不改變已儲存的偏好。
檔案數量與 diff 統計也反映目前顯示的差異。因此數字變小，不一定是作者撤回了修改。同一份 PR 的兩位讀者看到不同數字，可能只是篩選狀態不同。
找出格式變更下面的那一行
我們編寫了計算含稅價格的 JavaScript 範例。新版把結果四捨五入到小數第二位，同時將縮排從兩個空格改成四個。圖片是實際執行本機 git diff 的輸出，不是 GitHub 產品介面。
一般 diff 把計算式和 return 一起顯示為替換行。使用 git diff -w 後，計算式保留為脈絡，return 的變更更醒目。這樣較容易討論捨入規則、負數處理及既有測試。畫面更清楚有助於閱讀，但不代表修改已經正確。
空白本身也可能改變行為
Python 縮排、YAML 層級與字串內的空格都可能有意義。把 "Hello world" 改成 "Helloworld"，使用者看到的文字就變了。-w 控制空白比較方式，不會理解程式語言的語意。
在這個刻意簡化的字串範例中，-w 的輸出確實為空。第二張圖記錄實際執行結果。這不能證明 GitHub 和本機 Git 的所有行為相同，卻說明在空白有意義的地方，應再展開完整差異。
新檔案也能用上更多寬度
在 split view 中，新增及刪除的檔案現在橫跨兩欄。既然沒有舊版放在另一側，利用完整寬度很自然，也能減少長型別定義及測試名稱的折行。
遇到格式與功能混合的 PR，可先在隱藏空白時閱讀邏輯，再顯示空白檢查字串與結構。把格式化獨立成一個提交，也有助於傳達意圖。新偏好減少的是點擊與視覺雜訊，理解行為仍是審查核心。
官方資料
GitHub Docs · Reviewing proposed changes
2026年10月23日核對官方公告及 Git 文件，並在本機執行兩組比較。