最近我們團隊對日常開發規範和版本控制等工作進行了調整，爲此對GitFlow工作流以及它的各類變種也進行了學習，在此記錄一下。
只有一個Master分支帶來的問題
首先我們回顧一下我們在日常與團隊的合作開發一個項目中會遇到與版本控制相關的場景。
一般我們在創建一個Git倉庫的時候會有一個默認的主分支 master分支，默認情況下我們所有的開發工作（提交、合併。。）都在這個主分支上，也確實存在許多的團隊就在一個master分支上進行所有的開發活動。
那麼如果只有一個master分支會有哪些問題？
（1）場景一：當我們正在開發新的功能的時候，經理要求緊急上線一個版本
（2）場景二：已經上線的版本存在Bug,需要緊急修復，但是目前正在進行新功能開發。
顯然如果我們只有一個master分支，所有的版本發佈、Bug修復、新功能開發都在一個分支上開發，我們將會遇到許多問題，master分支上將同時存在正在開發中的代碼、已經開發完但未經測試的代碼、存在Bug的Tag版本等等一個比較混亂的情況。
如果此時想要發佈一個版本，我們必須從衆多的的提交記錄中找到一個最近但經過測試的TAG去發佈，但是我們修復Bug的提交可能不在這個TAG之前。。。。。
GitFlow解決問題的方式
GitFlow工作流如何通過多個分支解決 隨時發版、線上Bug解決、新功能同步開發等我們工作中經常遇到的問題？
一個典型的GitFlow工作流會包括 master、develop、release、以及feature分支
master分支是一個受到嚴格控制的主分支，所有的代碼在提交到master直接必須受到檢查，確保master上的代碼是功能完整、經過測試並隨時可以進行版本發佈的。
develop分支develop是開發分支，是所有分支中代碼最完整、最新的分支，確保所有的提交都會在develop分支中存在，在開發新功能時我們從develop分支上創建一個feature分支專門進行某一個功能的開發，當該功能完成後合併到develop分支此feature分支也會被刪除。
release分支是版本發佈分支，會存在 V1.0.1-release,V1.0.2-release。。。等衆多release分支，每個release分支都是從master分支上創建而來。
bugfix可以用來針對release分支進行Bug修復，屬於臨時分支，當修復了某個發佈版本的Bug後，需要同時將代碼合併到master和develop分支上。
。。。待續圖表整理