Git工作流程

FDD - Feature-driven development 功能驅動開發。
需求–>功能分支(feature branch)/補丁分支(hotfix branch)–>合併到主分支。 刪除功能分支/補丁分支。

---

1. Git Flow
   
   長期分支：
   專案存在兩個長期分支
   
   • 主分支master
   • 開發分支develop
     主分支用於存放對外發布的版本，任何時候在這個分支上的都是穩定的釋出版；develop用於日常開發，存放最新的開發版。

短期分支：
專案存在三種短期分支：
-功能分支（feature branch）
-補丁分支(hotfix branch)
-預發分支(release branch)
一旦完成開發，就被合併進develop或master,然後被刪除。

優缺點：適合waterfull的方式，缺點要經常切換分支，對於網際網路專案的持續釋出，同時維護兩個長期分支不大適合。
適合企業級應用系統開發。

1. Github flow
   

只有一個長期分支: master

1)根據需求，從master拉出新分支。
2）開發完成，向master 發出pull request
3) pull request評審與討論
4）pull request接受，合併進master。部署後，刪除分支。

優缺點：適合持續釋出。master上有可能不是穩定的程式碼。

1. Gitlab flow
   Gitlab集以上兩者之長，即有適應不同開發環境的彈性，又有單一主分支的簡單和便利
   Gitlab flow 的最大原則叫做”上游優先”（upsteam first），即只存在一個主分支master，它是所有其他分支的”上游”。只有上游分支採納的程式碼變化，才能應用到其他分支。
   

對於”持續釋出”的專案，它建議在master分支以外，再建立不同的環境分支。比如，”開發環境”的分支是master，”預發環境”的分支是pre-production，”生產環境”的分支是production。

開發分支是預發分支的”上游”，預發分支又是生產分支的”上游”。程式碼的變化，必須由”上游”向”下游”發展。比如，生產環境出現了bug，這時就要新建一個功能分支，先把它合併到master，確認沒有問題，再cherry-pick到pre-production，這一步也沒有問題，才進入production。