當前狀況 公司現行採用 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 來自動化：

Overview 什麼是提升 (Hoisting) 提升 (Hoisting) 的運作方式 文章中沒解釋的進階知識 什麼是提升 (Hoisting) 變數與函式在程式碼執行之前被『Hoisting』到作用域的頂部，這樣可以確保在執行程式時，所有變數與函式宣告都已經準備好可以使用 Hoisting 的設計主要是為了讓開發者在撰寫程式碼時更有彈性，最常見的是函式之間可以互相呼叫而不會導致錯誤 提升 (Hoisting) 的運作方式 JavaScript 是一個解釋型語言，解釋型語言指的是透過直譯器 (Interpreter) 逐行讀取並執行程式碼的語言，不過現今的 JavaScript 是透過 V8 引擎進行處理，V8 引擎提供『即時編譯(Just-In-Time Compilation, JIT)』，過程並不是逐行解釋程式碼而是先掃描整個程式碼，進行語法解析並生成機器碼(Bytecode)，在程式碼執行過程 (runtime) 會監控執行比較頻繁的程式碼將其編譯成機器碼以提升運行效能 現行的框架多數提供『提前編譯 (Ahead-Of-Time Compilation, AOT)』讓程式碼在部署前就提前編譯成機器碼，透過機器碼提升程式碼”啟動”的速度 JIT 側重於運行時的性能提升：因為會在執行過程中動態針對頻繁執行的程式碼進行深度優化，使長時間運行的應用程式 (Node.js Server) 效能更高 AOT 側重於啟動時的速度提升：因為提前將程式碼轉為機器碼，適合在意載入時間的應用程式 (網頁與行動裝置) Hoisting 發生於 JavaScript 編譯階段，而不是執行階段 當 JavaScript 編譯器掃描程式碼時，會將所有變數宣告和函式宣告『Hoisting』至作用域的頂部，這些宣告都會被記錄到記憶體中，此過程即為『Hoisting』，需注意的是，Hoisting 只 Hoisting 變數的宣告不 Hoisting 賦值，因此程式碼執行前 var 宣告的變數會被初始化為 undefined let 和 const 則會因『暫時性死區 (Temporal Dead Zone, TDZ)』的原因，若在宣告前使用該變數，會觸發 ReferenceError 參考以下實際例子的 Hoisting，主要是傳達概念，實際運作會更複雜 使用 var 的變數在宣告前就呼叫 編譯前

前言 最近想要抓實價登錄的資料來看，但是懶得去找可以免費 setup Server 的服務，但如果沒有一直在跑的 Server 怎麼去跑 Cron Job 來更新資料以及確保資料有被存放呢？ 於是就想說試試 GitHub Workflow 能不能達成這件事 XDD 如何設計 GitHub Workflow 基本上設計流程如下 Trigger Workflow by Schedule Run download-data Script Commit and push changes Trigger Workflow by Schedule 我們可以使用官方提供的 events-that-trigger-workflows#schedule ，來達到這個方式，他的時間結構如下 * * * * * ┬ ┬ ┬ ┬ ┬ │ │ │ │ └─ 星期 (0 - 6) │ │ │ └─── 月份 (1 - 12) │ │ └───── 月中的某天 (1 - 31) │ └─────── 小時 (0 - 23) └───────── 分鐘 (0 - 59) 因為實價登錄是每 10 天更新，但我避免誤差，所以設定成每個月的 02 / 12 / 22 號，因此我們的 Workflow 一開始會長這樣