Gitflow 工做流簡介

Gitflow工做流簡介

Gitflow工做流經過爲功能開發、發佈準備和項目維護分配獨立的分支，讓發佈迭代過程更流暢。

Gitflow工做流定義了一個圍繞項目發佈的嚴格分支模型，它會相對複雜一點，但提供了用於一個健壯的用於管理大型項目的框架，很是適合用來管理大型項目的發佈和維護。 貫穿整個開發週期，master和develop分支是一直存在的，master分支能夠被視爲穩定的分支， 而develop分支是相對穩定的分支，特性開發會在feature分支上進行，發佈會在release分支上進行，而bug修復則會在hotfix分支上進行，這樣也有效避免了不一樣類型的開發工做在代碼層級的耦合和干擾。

一、歷史分支

Gitflow工做流使用2個分支來記錄項目的歷史。 master分支存儲了正式發佈的歷史，而develop分支做爲功能的集成分支。 這樣也方便master分支上的全部提交分配一個版本號。

二、功能分支

每一個新功能位於一個本身的分支，這樣能夠push到中央倉庫以備份和協做。 但功能分支不是從master分支上拉出新分支，而是使用develop分支做爲父分支。 當新功能完成時，合併回develop分支。 新功能提交應該從不直接與master分支交互。

三、發佈分支

一旦develop分支上有了作一次發佈（或者說快到了既定的發佈日）的足夠功能，就從develop分支上checkout一個發佈分支。 新建的分支用於開始發佈循環，因此從這個時間點開始以後新的功能不能再加到這個分支上，這個分支只應該作Bug修復、文檔生成和其它面向發佈的任務。 一旦對外發布的工做都完成了， 發佈分支合併到master分支並分配一個版本號打好Tag。 另外，這些重新建發佈分支以來的作的修改要合併回develop分支。使用一個用於發佈準備的專門分支，使得一個團隊能夠在完善當前的發佈版本的同時，另外一個團隊能夠繼續開發下個版本的功能。

四、維護分支

維護分支或說是熱修復（hotfix）分支用於快速給產品發佈版本（production releases）打補丁， 這是惟一能夠直接從master分支fork出來的分支。 修復完成，修改應該立刻合併回master分支和develop分支（當前的發佈分支），master分支應該用新的版本號打好Tag。爲Bug修復使用專門分支，讓團隊能夠處理掉問題而不用打斷其它工做或是等待下一個發佈循環。

若是你沒有認識到這個工做流頗有用，那多是由於你的開發工做尚未複雜到一個程度，一個必需要規避代碼干擾、保證並行推動的程度。

參考資料

GitFlow 工做流