進公司一陣子之後，近期幫公司推動的是CICD、git flow開發流程。 長期下來這是有必要的，能讓開發流程更順、也能省下不少時間。公司是以main 做為開發分支但並沒有訂好開發流程，一個git commit 打片天下無敵手，這樣弊利於多。就我看到的現象「大致上很多改動都是以上傳FTP 為主、檔案在開發時互相蓋來蓋去，也很難找回覆蓋的部分。dev 分支有好幾個、開發的環境和dev無法對齊、main 隨時會因為一個git commit 爆、沒有PR 的習慣、沒有回朔版本」。 1. 訂下gitflow→ Trunk-Based Development (TBD) 進來的時間就推動git flow 流程，定主線main 、 開發分支dev、branch 保護原則:main、dev，合併前都必須發PR、合併採merge squash。 到後期改採TBD( Trunk-Based Development )比較符合短快準的開發流程，啟因「git flow 流程上dev的某功能被同步於main佈署上去 但未完成測試 以至於 正是產品爆掉了」，所以後來改採 沒問題就正式放到main 、開發的副本 一率從main 切，減少開發分支不穩定。 2. 設定branch 保護的rulest 由於git commit，由於main 、dev 沒有保護 變成任一merge 都能改變main，main 的時間線會變得很亂，於是就加了rulest 保護原則。 3. CICD 自動佈署 DEV自動佈署到測試環境加速自動開發、MAIN 佈署到正式環境。 以往MAIN 佈署是由同事→組長→佈署更新正式。 現在是環境測完沒問題，同事→佈署更新正式，那git 上會自動留存一份佈署的PR紀錄、誰佈署了什麼功能都能追查、減少了組長的工作、同事的等待時間。 main 自動同步到 dev，能確保dev 與main 對齊。 發PR 會有說 目前是合到哪個分支的自動留言
