Gitflow 工作流簡介
Gitflow工作流簡介
Gitflow工作流通過為功能開發、釋出準備和專案維護分配獨立的分支，讓釋出迭代過程更流暢。
Gitflow工作流定義了一個圍繞專案釋出的嚴格分支模型，它會相對複雜一點，但提供了用於一個健壯的用於管理大型專案的框架，非常適合用來管理大型專案的釋出和維護。 貫穿整個開發週期，master和develop分支是一直存在的，master分支可以被視為穩定的分支， 而develop分支是相對穩定的分支，特性開發會在feature分支上進行，釋出會在release分支上進行，而bug修復則會在hotfix分支上進行，這樣也有效避免了不同型別的開發工作在程式碼層級的耦合和干擾。
1、歷史分支
Gitflow工作流使用2個分支來記錄專案的歷史。 master分支儲存了正式釋出的歷史，而develop分支作為功能的整合分支。 這樣也方便master分支上的所有提交分配一個版本號。
2、功能分支
每個新功能位於一個自己的分支，這樣可以push到中央倉庫以備份和協作。 但功能分支不是從master分支上拉出新分支，而是使用develop分支作為父分支。 當新功能完成時，合併回develop分支。 新功能提交應該從不直接與master分支互動。
3、釋出分支
一旦develop分支上有了做一次釋出（或者說快到了既定的釋出日）的足夠功能，就從develop分支上checkout一個釋出分支。 新建的分支用於開始釋出迴圈，所以從這個時間點開始之後新的功能不能再加到這個分支上，這個分支只應該做Bug修復、文件生成和其它面向釋出的任務。 一旦對外發布的工作都完成了， 釋出分支合併到master分支並分配一個版本號打好Tag。 另外，這些從新建釋出分支以來的做的修改要合併回develop分支。使用一個用於釋出準備的專門分支，使得一個團隊可以在完善當前的釋出版本的同時，另一個團隊可以繼續開發下個版本的功能。
4、維護分支
維護分支或說是熱修復（hotfix）分支用於快速給產品釋出版本（production releases）打補丁， 這是唯一可以直接從master分支fork出來的分支。 修復完成，修改應該馬上合併回master分支和develop分支（當前的釋出分支），master分支應該用新的版本號打好Tag。為Bug修復使用專門分支，讓團隊可以處理掉問題而不用打斷其它工作或是等待下一個釋出迴圈。
如果你沒有認識到這個工作流很有用，那可能是因為你的開發工作還沒有複雜到一個程度，一個必須要規避程式碼干擾、保證並行推進的程度。