GitHub Push Rulesets 路徑例外怎麼設？限制檔案又保留必要例外
GitHub 在 2026 年 8 月 25 日為 Push Rulesets 加入 path exceptions 公開預覽。規則可以在整個套用範圍限制檔案路徑或檔案大小，同時為少數已審核的路徑保留例外；這比把整條規則關掉更容易維持安全邊界。
直接答案是：先建立最窄的阻擋 pattern，再在該規則的 Allowed exceptions 加入明確路徑，最後用測試 push 驗證「應擋」和「應放行」兩種結果。 path exception 是規則內的例外，不是給某個人的 bypass 權限，也不應用一個寬泛的 ** 取代審查。
目前哪兩種 push rule 支援路徑例外
這次公告目前列出兩個支援 path exceptions 的規則：
| 規則 | 沒有例外時 | 有例外時的用途 |
|---|---|---|
| Restrict file paths | 阻擋符合指定路徑的 commit 被 push | 禁止整個 repository 出現敏感檔案，但放行固定的 fixture 或必要 wrapper |
| Restrict file size | 阻擋超過大小上限的檔案被 push | 維持大檔門檻，但放行已審核、不可拆分的特定檔案 |
GitHub 文件將 Restrict file paths 描述為阻止指定檔案路徑的 commit 被推送，pattern 使用 fnmatch 語法。規則本身最多 200 個 entries、每個 entry 最多 200 個字元；例外也應維持同樣可讀、可盤點的粒度。
在 ruleset 編輯畫面加入例外
GitHub Changelog 的操作路徑是規則編輯畫面中的 Allowed exceptions：
- 建立或開啟 repository 的 Push Ruleset，先確認 target repository 與 enforcement 範圍。
- 加入 Restrict file paths 或 Restrict file size，先寫出要阻擋的 pattern 或大小上限。
- 展開該規則的 Allowed exceptions，新增已通過審查的 path pattern。
- 儲存前閱讀 GitHub 對 pattern 的驗證結果；格式不正確時先修正，不要靠 push 失敗才猜規則。
- 用測試分支建立兩個最小 commit：一個命中阻擋規則，一個只命中例外，確認結果符合預期。
範例一：禁止 .jar，只放行 Gradle wrapper
假設 repository 不允許任意 Java archive，但保留固定的 Gradle wrapper jar。可以把阻擋與例外拆成兩層：
Restrict file paths blocked pattern: **/*.jar allowed exception: **/gradle/wrapper/*.jar這個例外只針對符合路徑的 wrapper 檔案，不會讓 vendor/、downloads/ 或其他資料夾的 .jar 一起放行。實際 pattern 仍要用 repository 內的路徑做測試，因為資料夾命名和 glob 深度會改變匹配結果。
範例二：大檔限制只放行一個已審核檔案
如果團隊要把一般 push 的檔案限制在 10 MB，但某個已審核的二進位檔必須保留，可以把例外限定到完整路徑：
Restrict file size maximum file size: 10 MB allowed exception: assets/approved-model.bin這不等於該檔案永遠不需要更新審查。檔案內容、來源、版本和更新頻率仍應由 code review、release 流程或 artifact registry 管理；path exception 只處理 push ruleset 的檔案邊界。
例外 pattern 的四個安全檢查
1. 先問「哪一個檔案必須放行」
例外最好指向明確檔案或窄資料夾，而不是整個 repository。**、**/* 或只有副檔名的寬泛例外，通常會讓原本的規則失去意義。若真的要放行一組檔案，寫出可由 reviewer 讀懂的目錄邊界。
2. 把測試檔和 production 檔分開
fixtures/、testdata/ 或 wrapper 檔案是常見例外，但不要因為一個測試需要 binary，就把 production 同類型檔案全部放行。至少測試：例外內的檔案、例外外的同副檔名檔案、相鄰資料夾和巢狀資料夾。
3. 不要把 bypass 當成 path exception
Path exception 會改變某條規則的匹配範圍；bypass 則是讓特定使用者、團隊或 GitHub App 略過 ruleset。兩者的稽核問題不同。Push Ruleset 的 bypass 權限還會套用到 repository 的整個 fork network，所以更不應為了方便把 release bot 設成萬用 bypass。
4. 把公開預覽視為需要回歸測試的功能
這項功能目前是 public preview。正式採用前保留 ruleset JSON、pattern、例外理由與測試結果；若規則行為變更，才有足夠資料比較。若團隊正在從 Branch Protection 遷移，也要先看 Branch Protection 轉 Rulesets 的驗證流程，不要把 push rules 和 PR merge rules 混成同一個政策。
一份最小驗證清單
[ ] blocked pattern 在預期路徑會拒絕 push[ ] allowed exception 只放行預期檔案或資料夾[ ] 同副檔名的其他路徑仍會被拒絕[ ] 大小剛好在上限與超過上限各測一次[ ] bypass actor 沒有被意外擴大[ ] pattern、例外、理由和測試 commit 已留下紀錄規則真正上線後，仍要觀察第一次真實 release、依賴更新和 fork push。若出現誤擋，優先縮小 pattern 或增加一個有理由的例外；不要直接停用整條 Push Ruleset。
常見問題
Q: Path exception 可以放行任何 push rule 嗎？
A: 目前 GitHub 公告列出的支援範圍是 Restrict file paths 與 Restrict file size。其他 push rule 是否有相同 UI 或語意，要以目前 ruleset 畫面與官方文件為準，不要預設所有規則都支援。
Q: 例外路徑和 bypass actor 哪一個比較好？
A: 如果例外是「某些檔案可以被推送」，用窄的 path exception；如果例外是「某個受控的使用者、團隊或 App 可以略過整條規則」，才考慮 bypass。bypass 的範圍更大，也要另外做身份、權限與稽核設計。
Q: Push Rulesets 會取代 Branch Protection 嗎？
A: 不會。Push Rulesets 管的是 push 進入 repository 或 fork network 時的檔案邊界；Branch Protection 或 PR rulesets 管的是分支與合併條件。兩者可以一起存在，應分別驗證。
參考資料：
GitHub Changelog：Push rules in rulesets now support path exceptions
回報錯字、失效連結，或告訴我你想看的延伸主題。