支持原創(chuàng)，原文地址：www.KentonYu.com
又是一段時間沒寫博客了。。一直生活在甲方的世界里。。。可能也是自己懶癌復(fù)發(fā)了吧。。
最近一個項目，因為需求上比較容易（開發(fā)時間比較充裕），所以嘗試了通過Git Flow來管理項目源代碼，從而探索下是否可以提高整體開發(fā)效率。在這之前，公司用的只是dev + master，幾個開發(fā)同時在dev上開發(fā)，時不時就會有沖突，特別是項目中的xib文件較多時，很容易發(fā)生xib沖突（頭疼。。。當然只要在commit之前看下文件變更記錄，把不需要的變更放棄掉，但是難免會有疏忽的時候）。
- Git Flow 介紹
Git Flow是構(gòu)建在Git之上的一個組織軟件開發(fā)活動的模型，是在Git之上構(gòu)建的一項軟件開發(fā)最佳實踐。Git Flow是一套使用Git進行源代碼管理時的一套行為規(guī)范和簡化部分Git操作的工具。
Git Flow 全貌
其實學(xué)習(xí)Git Flow，主要還是理解幾個分支的用處，在使用時通過嚴格的分割，將沖突概率降到最低，提高開發(fā)效率。下面我就按自己的理解來描述下主要的幾種分支。
master
這個分支上只存在上線版本，每個commit都應(yīng)該對應(yīng)一個版本號。
僅在發(fā)布新的可供部署的代碼時才更新master分支上的代碼
develop
dev分支簡單來說就是開發(fā)分支，它保存著開發(fā)過程中的最新版本。也就是說每當完成一個需求（feature）就應(yīng)該合并到dev分支上。
feature
feature：功能。這個分支顯而易見，是用來存每一個新功能（需求）的。每一個功能模塊（較復(fù)雜的最好拆分下）可以做為一個feature。一般情況，每一輪迭代結(jié)束后的feature分支都應(yīng)被合到dev分支上。這類分支也可以是做為實驗性分支，比如在上面嘗試一些開發(fā)，如果達不到預(yù)期效果也可以放棄該分支。
release
release分支可以看做是存儲上線版本之前的分支。用一個實際情況來描述下，第二輪sprint結(jié)束，需要上線一個版本（還未進行測試和fix bugs），這時候第三輪sprint又要開始了。根據(jù)之前master的原則，是只存在上線版本的，因此我們可以用release分支，存一個待上線版本，然后dev就可以進行sprint3迭代了。這時候sprint2的bug 就可以在release上修復(fù)，當測試通過之后，就可以將release合進master上，同時dev需要merge下release分支。
hotfix
hotfix：熱補丁。它的作用是線上版本出現(xiàn)bug時，可以通過hotfix來fix，然后產(chǎn)生一個新的發(fā)布版本，合并到master上，同時dev需要merge hotfix。這樣的好處是可以打斷dev上正在開發(fā)的進度。
以上就是Git Flow模型的大致概念。在實際開發(fā)過程中，這個模型并不是一成不變的，根據(jù)每個開發(fā)團隊或每個項目可以進行一定的變化。
-
Git Flow 實際使用
日常開發(fā)中，使用SourceTree來操作Git居多。SourceTree中自帶Git 工作流模型，簡單的使用只需要點擊應(yīng)用即可。
SourceTree 自帶工作流
當然這邊也可以進行自定義，或者說不使用這個模型，自己通過新建分支來實現(xiàn)Git Flow。
我實際運用中，大致是這樣的：
心得
1.dev有更新時，feature分支及時rebase（變基，衍合），不然當合并該feature時可能會出現(xiàn)很多沖突（Q_A_Q）。
2.可以復(fù)用頁面的一些功能模塊應(yīng)該分配給同一個開發(fā)去做，不然在頁面復(fù)用上會有問題。因為每個feature是分割開的。引用
1.基于git的源代碼管理模型——git flow http://www.ituring.com.cn/article/56870
