很是清晰明瞭的GIT版本管理圖

Git版本管理方法

  Git和SVN是咱們代碼開發中，最經常使用的兩款代碼管理軟件。在這裏我來寫寫我在工做中如何使用Git來管理咱們的代碼開發。
  首先，咱們是一個多人開發的團隊，所以在開發過程當中，少不了要進行多人協做的時候。不一樣的功能分支就成了屢見不鮮的事情了。咱先來看一副圖：

GitFlow.png

  這幅圖裏畫的是我平常工做中，代碼管理中Git分支的存在形式。從最上層的一行中能夠看到，通常會存在一些這樣的分支：

>>Master: 主分支；主要是穩定的版本分支，正式發佈的版本都從Master拉。>>Develop: 開發分支；更新和變更最頻繁的分支，正常狀況下開發都是在Develop分支上進行的。>>Release：預發行分支；通常來講，表明一個版本的功能所有開發完成後遞交測試，測試出Bug後進行修復的分支。>>Features: 功能分支； 其實Features不是一個分支，而是一個分支文件夾。裏面包含了每一個程序員開發的功能點。Feature開發完成後合入Develop分支。>>HotFix: 最但願不會被建立的分支；這個分支的存在是在已經正式上線的版本中，發現了重大Bug進行修復的分支。

  介紹完了幾個分支的主要功能，咱們能談談一個具體的App軟件版本開發中的流程。
一、軟件版本的起點：A
  需求老是在不斷更新的。
  上一次產品經理需求0.1的軟件版本剛剛完成後，這不又來了新的版本需求0.2，此次一共兩個功能點。幸虧咱們有Git，讓並行開發成爲可能。拉取Develop分支準備開幹！

二、開發的起點：B
  兩名工程師，兩個不一樣的需求，大師甲和大師乙各自領取一個功能點開幹；從Develop拉取屬於本身的分支，有單獨的分支就不會被幹擾：）

三、開發的終點：H
  一週不到，兩位大師就已經完成了屬於本身的功能；從圖上看，都有兩次代碼的提交。大師們各自開發的功能初步看彷佛沒 有啥問題，可是咱們的App版本是一個多功能的集合，是否合在一塊兒也會沒有問題？這時候大師們把屬於本身的分支合入Develop，並刪掉本身的工做 Branche。編譯，運行，Success!

四、預發行的起點：Release 0.2 節點(I)
  大師們的能力果真不同凡響，合入後沒有一點問題，達到提交測試部的標準。新建Release 0.2 分支，表明一個里程碑式的事件。

五、Release 分支Bug宿命
  世上沒有哪一個大師的代碼是沒有Bug的，大師甲和大師乙也不例外。這不，測試部剛拿到預發行的版本就曝出了2個Bug。
  不過沒有關係，可以復現的Bug對於咱們來講就不是Bug。從Release 0.2拉取Bug修復分支。修好了，繼續合進Release 0.2。誰叫Release就是這樣的宿命呢。

六、版本發行的終點: M
  希望人長久，Bug再也不有。
  通過大師們堅苦卓絕的bug修復，終於經過了測試部的測試，也獲得了產品經理們的承認，準備提交App Store審覈。
  Release合入Master分支，打上Tag 0.2，這就是此次的MileStone了。
  固然也得記得Release合入Develop，以前這麼多的bug也得在Develop上修復修復不是。作好了這些，Release就能夠刪啦。

七、救火隊員通常的HotFix: N
  好事多磨！AppStore剛發出去的App, 就有用戶反饋Crash! 大師甲和大師乙臨危受命!
  從Master拉取HotFix分支來搞定它。原來是數組越界！分分鐘搞定。完成後合入Master，版本更新爲Tag 0.3，表明咱們修復了重大問題。編譯，運行，沒問題，提交App Store等審覈。
  噢，one more thing, HotFix 也要合入Develop，又多了一個功能點（bug修復）不是。

八、新的輪迴開始：P  1-> 7就是一個版本的開發過程當中，咱們的Git Flow流。到了最後，P和O節點擁有了相同的內容，就像在一開始的A和B那樣。  這時候，我看見產品經理又拿着版本需求1.0向我走來......