當前狀況 公司現行採用 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 的變數在宣告前就呼叫 編譯前

Overview 工作上開始接觸 RTC SDK 相關的開發，想起過去有分享過 WebRTC 的運作原理，趁著週末有空檔來重新複習一下。 什麼是 WebRTC？ WebRTC (Web Real-Time Communication) 是一個開放標準，用於在瀏覽器中不需安裝額外插件，即可實現實時音訊、視訊和數據傳輸。 基本上視訊會議都是透過 WebRTC 來實現，幾乎所有即時互動功能都會用到 WebRTC，而常見的的遊戲直播，基本上延遲會比較高，主要使用的技術應該是串流 (Streaming) 來實現，這邊要注意一下。 WebRTC 的核心概念 我們可以透過模擬兩位董事長要進行開會來學習 WebRTC 的運作原理： 告知秘書準備要開會: 創建 PeerConnection 實例，並設定 ICE 連線通道的名單 董事長請秘書把名片交給對方： 使用 SDP 交換彼此的資訊 確認要在哪個會議室進行談話: 使用 ICE 協定來確認彼此的網路狀態 雙方開始進行對話: 完成 P2P 連線，開始進行對話 1. RTCPeerConnection：建立連線的起點 秘書就像是 RTCPeerConnection 實例，它是 WebRTC 連線的核心。我們需要先建立這個實例，才能開始後續的所有步驟。 而 PeerConnection 實例的創建，通常會在準備建立連線時就創建，這樣才能確保後續交換資訊與連線順利進行。 在創建實例時，我們通常會提供一組 ICE 伺服器 (STUN/TURN) 的設定，這就像是告訴秘書可能有哪些會議地點可以選擇。 2. SDP (Session Description Protocol)：交換名片 在對談中我們需要知道名字，對方講什麼語言，興趣是什麼，才能順利的進行對話，而這在 WebRTC 裡就是透過 SDP (Session Description Protocol) 來交換彼此的資訊。