提到主幹開發，你會想到什麼？

過去有聽過朋友對於主幹開發的印象是「不開分支」或「直接把程式碼推上主幹」。

我會回答：「是這樣！但不是這樣！」

確實在主幹開發的流程中，可以不開分支，也可以直接把原始碼推上主幹，但輪到自己要照著做的時候，會突然覺得這根本是真勇者的版控流程，沒有想像中的簡單。

舉幾個例子：大家都往同一條主幹整合，那要如何保護主幹？開發到一半還不能用的功能怎麼先合併？長期的改版計劃又該如何逐步進行？

具體做法可能不同，但主幹開發強調的重點是：頻繁地把變更整合到共同主幹，並維持可發布的狀態。而如何解決執行過程遇到的問題，才是主幹開發真正困難的地方。

接觸主幹開發的經歷

2015 年，前輩介紹了主幹開發給我，在這之後我持續學習並嘗試實踐，也遇到了不少困難，同時也深刻體會到主幹開發「是這樣！但不是這樣！」

後來，我陸續在研討會分享相關主題，主要都是功能標誌相關的介紹。2023 年，我在 LaravelConf 帶領功能標誌工作坊，也在 DevOps Taiwan Meetup 與 DevOpsDays Taipei 分享主幹開發。

當年的參與經歷，整理在這篇研討會心得裡，有興趣可以參考看看。

2024 年，透過 DevOpsDays Taipei 大會聯絡 Paul Hammant 並取得翻譯許可後，我擔任翻譯團隊的主要負責人，和夥伴一起把主幹開發網站翻成正體中文，很感謝翻譯團隊一起把這件事完成。

而這次，我想把過去的經驗整理成系列文章，說明主幹開發實際做法、適用條件與限制，讓讀者能依自己的團隊情況，判斷哪些做法適合採用。

這 30 天會寫些什麼

• 版本控制與團隊協作：版本控制是開發協作的基礎。說明版本記錄、分支隔離與合併衝突，以及任務互相依賴時，團隊如何取得並整合彼此修改的程式。
• 整合與發布：直接提交與短期分支的選擇、程式碼審查、建置與測試、任務拆分，以及從主幹或發布分支交付程式的做法。
• 功能標誌與抽象分支：透過設定控制功能是否啟用的功能標誌，以及透過共同介面讓新舊實作並存、逐步替換的抽象分支。討論如何在功能尚未完成或改版進行中，持續整合並維持可發布的狀態。
• 舊系統與大型版本庫：如何從舊系統逐步替換成新系統，以及大型版本庫的整合與驗證。
• 日常習慣與上線後的觀察：團隊如何維持主幹穩定、面對發布計劃變化，以及確認上線後的結果是否符合預期。

這個系列適合誰看

如果你使用過版本控制系統，也有和別人一起修改原始碼的經驗，就可以閱讀這個系列，不需要先有主幹開發的經驗。

文章會盡量用具體情境、流程與程式範例說明。說明案例時，也會交代必要的背景，方便讀者理解每一步的目的，以及預期會得到什麼結果。

需要其他領域的知識時，例如分析業務需求或觀察上線後的運作情況，我會說明它的用途，並提供延伸閱讀。

下一篇，先從多年前我與朋友一起接的一個網站案子說起，聊聊當時我們怎麼管理共同修改的原始碼。

參考資料

• Trunk Based Development: Introduction
• Trunk Based Development: Feature Flags
• Trunk Based Development: Branch By Abstraction