上版新功能時，可以直接以 feat 分支合併到 main 嗎？

• 通常都會直接用 develop 分支併到 main，接著上版到正式機，方便合併完且測試後的版本上線。
• 如果有遇到某個新功能必須先上線，但 develop 混著好幾個還正在進行測試的 feat 分支，這時就會採取以個別 feat 合併到 main 的方式來操作。
• 其實直接將開發完的 feat 分支且已到 develop 測試過的功能，直接合併到 main 對於分支管理更能夠保留了每個功能的獨立性與可追溯性。

新功能開發時程較長，期間其他功能開發完畢已上版數次，如何減少併到 develop 的衝突？

• 開發過程，定時將 remote 的 develop 拉下來 local，與正在開發的 feat 分支合併，可避免過多衝突，減少併版花費時間。

Code Review 與功能測試後，發現還有需要開發人員更新的程式碼與功能⋯⋯

1. 直接在 GitHub 介面說明更改方向。
2. 在 PR 中留下 comment，說明測試發現的問題。
3. 等待都修改至正確版後，merge 完後 close 掉 PR，這麼一來，就不需再發第二次 PR。

導入 Git Workflow 心得

---

剛開始導入 Git Workflow 時，團隊一度有點手忙腳亂，大家都還不太熟悉操作，小如：「分支要取什麼名字」，大到：「分支要自己 merge 嗎？」（這樣有大嗎？🤣）各種問題都接連提出來討論，甚至有時連我自己也搞不清楚自己畫的工作流程。

不過，隨著大家的互相協作和逐漸摸索，逐步釐清了這些問題，並確立了清楚的規則。團隊現在已能依照既定的工作模式進行分支管理，不僅減少了程式碼衝突，也能追蹤每個功能的開發狀況。

大家可以試著找到適合自己團隊專案的 Git Workflow ，導入後再慢慢調整與優化。隨著工作流程建立後，接著可以加入更多規範與細節原則，讓程式碼可管理性提高。在接下來的文章中，將繼續分享有關管理程式碼方面的內容，請大家繼續看下去吧！😛