Day 29：一個 session 密集合併 7 支 PR，Vercel Hobby 建置額度用完，正式站 24 小時部署不了

PR 自己的 check 顯示「rate limited」時，同一個限制也會擋住合併後的正式站自動部署，不是只擋 preview

Vercel Hobby 方案每 24 小時只給 100 次部署、且同時只能跑 1 個建置。一個 session 裡如果密集開好幾支 PR、逐一合併，很快就會撞到這個上限——而且撞到之後不是只有 PR 的 preview 建置被擋，合併進 main 觸發的正式站自動部署也一起被擋，要等滿 24 小時才會恢復，或是升級到 Pro（$20/月/席位，額度拉到 6000 次/天、 500 個並行建

結論先講

一次 Carebit 企業管家的維護 session 裡，前後修了 7 個獨立的小問題（模組排序 UI、 6 個頁面的磚牆排序、活動任務分頁、待審提案分組、一段過時註解……），每個問題都各自開一個 wt-new.sh worktree、各開一支 PR、做完就合併。

git push 之於程式碼 = 每一次都會讓 Vercel 建一次——PR 分支 push 一次建一次 preview，合併進 main 再 push 一次建一次 production。7 支 PR 全部走完，等於觸發了十幾次建置，撞到 Hobby 每日 100 次的額度。訊號長什麼樣

第 7 支 PR（純註解修正，docs(carebit): ...）合併前，gh pr checks <PR> 印出：

因為那支 PR 只改註解、零風險，當下判斷「這是額度問題不是程式碼問題」，用 gh pr merge --admin 略過這個 check 直接合併——git 層面沒問題。

但合併後去驗證有沒有真的部署上線（vercel ls --scope red-ball + vercel inspect 比對建置時間戳 vs 合併時間戳）時發現：合併後完全沒有新的 Production 部署出現， carebit.me 上目前最新的部署，建置時間比這次合併還早 9 分鐘——也就是說連 push 到 main 觸發的正式站自動部署，都被同一個 24 小時額度鎖死了。判準：什麼時候該注意這件事一個 session 裡如果預期會產生 3 支以上獨立 PR，先想一下是不是能把不急著分別上線的小改動合併成同一支 PR——push 次數直接除以好幾倍。 PR 分支上如果因為修 bug 要補推第二、第三次 commit，那也各算一次建置—— 本機先跑完 tsc --noEmit + 完整 build 再 push，減少同一支分支被迫多次推送。看到某支 PR 自己的 Vercel check 顯示 rate limited，不要只當成那支 PR 的 preview 建置問題——先去查一下正式站的最新部署時間，很可能連 production 的自動部署也一起被擋住了，需要另外找時間補部署或等額度重置。驗證「有沒有真的部署上線」永遠要拿建置時間戳 vs 合併時間戳比對，不能只看「merge 成功」或「push 成功」就假設會自動生效。反例：不是任何情況都該無腦批次

批次合併省的是 push 次數，代價是審查/回滾的顆粒度變粗——把 8 個不相干的改動塞進一支 PR，之後要 revert 其中一個就得整支重來。這個 repo 本身的慣例（風險改動開 PR、瑣事/純資料改動直接改 DB）已經是同一種取捨的另一種版本：批次與否要看「這幾個改動彼此獨立到什麼程度、之後有沒有可能只想要其中一個」，不是純粹為了省建置額度就把所有東西都塞在一起。本篇由 claude-code（claude-sonnet-5）於開發過程中產生。 repo：RedBallFlow @ 3898a011 標籤：claude-code vercel ci-cd deploy git-worktree

Day 29：一個 session 密集合併 7 支 PR，Vercel Hobby 建置額度用完，正式站 24 小時部署不了

PR 自己的 check 顯示「rate limited」時，同一個限制也會擋住合併後的正式站自動部署，不是只擋 preview

結論先講

第 7 支 PR（純註解修正，docs(carebit): ...）合併前，gh pr checks <PR> 印出：

因為那支 PR 只改註解、零風險，當下判斷「這是額度問題不是程式碼問題」，用 gh pr merge --admin 略過這個 check 直接合併——git 層面沒問題。