當前狀況 公司現行採用 GitHub Flow 進行分支管理。雖然我們大致上每週 Release 新版本，但有時會因 Hotfix 或功能實驗，導致 Release 節奏被打亂，產生以下問題： main branch 可能被提前合併未來要 Release 的功能 若上線後需修正，又要 revert 其他功能或暫時禁止合併 需要人工確認各種狀態，流程繁瑣且易出錯 為了解決這些問題，我們導入了所謂的「GitHub Merge Freeze」機制，也就是在 Release 期間，透過 GitHub Actions 自動凍結 main branch，確保版本穩定。 解決方案：Release PR + Merge Freeze 我們優化後的流程如下： 每次 Release 時建立 Release PR，將本次要上線的功能統一合併，Release 完再 merge 回 main。 Release PR 存在期間，main branch 禁止合併任何新的 PR，僅能合併到 release branch。 這麼做的好處： 所有 Release 內容一目了然，方便查驗和追蹤 自動 freeze main branch，開發者一目瞭然，降低溝通成本，避免誤合併 如何自動 Freeze Main Branch？ GitHub 原生僅支援 手動鎖定分支，並無自動 freeze 功能。因此，我們設計兩個 GitHub Workflow 來自動化：

這是關於整理報表時，遇到兩個模組間邏輯會打架的工作雜記，以下除了處理過程相似，其他模組與表格都是虛構 故事脈絡 最近遇到要把以前的報表新增加權分數(weighted_score)的欄位，而報表資料主要是從使用者評分表 Table 撈取出來整理的，加權分數以前是在其他模組計算但沒有被存放到 Table 中，使用者評分表的 Schema 簡化後大概如下 欄位名稱 資料類型 說明 id INT(PK) 主鍵 user_id INT(FK) 外鍵 value INT 新增/扣除的分數 params JSON 放置分數相關的任意資料 confirmed BOOLEAN 已經評分過的資料為 true 範例資料 id value user_id params confirmed 1 122 12 { “type”: 1, “weighted_score”: 456 } 0 2 19 11 { “type”: 2, “weighted_score”: 314 } 1 處理過程 建立共用的模組 由於以前的程式碼在計算加權分數時是直接計算，而加權分數其實會因為不同類型的type而有不同的加權計算方式，為了在報表也能使用這套邏輯，所以我們需要先抽出一個模組 Calculator ，慶幸的是這套邏輯已經有寫測試，所以我們可以省掉寫測試的時間直接重構即可，這邊我是使用工廠模式來處理，後續直接套用模組跑測試無誤就算是完成這個階段，可以到下一個階段進入資料的處理惹。 將計算完的資料放進 Table 中 這邊介紹一下會用到的兩個模組，模組 D 是負責進行使用者扣分的模組，而模組 DeductPoint 是接收到扣分行為時會去使用者評分表把扣分的資料寫入進去，有個需要注意的地方是，扣分會先從確認過(confirmed = 1)的分數先扣不夠再從未確認(confirmed = 0)的分數扣，所以有可能會一次扣分行為但記錄兩筆資料到使用者評分表…