使用 Bash 製作一個 release 分支自動同步工具
注意到一個反覆出現卻又容易被低估的痛點：當從主幹分支切出 release 分支後，接下來一到兩週內，每個落在主幹上的 hotfix 都必須被 cherry-pick 回到 release 分支，而任何一個錯誤都會讓 release 分支處於不一致的狀態。
注意到一個反覆出現卻又容易被低估的痛點：當從主幹分支切出 release 分支後，接下來一到兩週內，每個落在主幹上的 hotfix 都必須被 cherry-pick 回到 release 分支，而任何一個錯誤都會讓 release 分支處於不一致的狀態。
近期在開發 Go 專案時發現到提交代碼流程總是有些摩擦，像是開發時習慣用 Tab 到 GitLab 上寬度就會變得很奇怪，或是一些簡單的對齊問題都在無形消耗專注力。所以透過把一些原生的 Go 靜態檢查工具搬到 CI 上執行，確保統一的開發體驗。
在先前的文章提到如何使用 Lighthouse 這款工具監控前端大大小小的最佳實踐，例如：效能、SEO、適用性……等能被客觀測量比較的數值，雖然很方便但你可能會希望自架 Lighthouse 服務，以便實現：蒐集與管理自己的隱私資料、持續性監控同個網站的檢測資料、減少依賴第三方伺服器服務。
網頁東東至今仍完全以本地為主，所有代碼、字體、圖片影片與文章內容都紀錄於 Git 當中，並透過 Git LFS 來管理大檔案。這樣的決定有好有壞，其中一個問題便是內容與代碼的耦合高，任何一個想維護的人要把我撰寫的幾百篇文章連帶抓下來 😅，隨著專案成熟我決定要將兩者分離。
使用套件時總是會好奇一般管理套件開發的流程是如何？我透過 Matt Pocock 的 Blazing Fast Tips: Publishing to NPM 教學影片順手實作了一次，並且把自己之前遇過的需求寫成一個獨立的 TS 套件公開發布：edit-element。