Gitflow工作流程圍繞項目發布定義了嚴格的分支模型。盡管它比Feature Branch Workflow更復雜一些，但它也為管理更大規模的項目提供了堅實的框架。
與Feature Branch Workflow比起來，Gitflow流程並沒有增加任何新的概念或命令。其特色在於，它為不同的分支分配了非常明確的角色，並且定義了使用場景和用法。除了用於功能開發的分支，它還使用獨立的分支進行發布前的准備、記錄以及後期維護。當然，你還是能充分利用Feature Branch Workflow的好處：拉拽請求（Pull Request）、隔離的試驗以及更高效率的合作。
流程仍然使用一個中央代碼倉庫，它是所有開發者的信息交流中心。跟其他的工作流程一樣，開發者在本地完成開發，然後再將分支代碼推送到中央倉庫。唯一不同的是項目中分支的結構。
用於記錄歷史的分支
Gitflow使用兩個分支來記錄項目開發的歷史，而不是使用單一的master分支。在Gitflow流程中，master只是用於保存官方的發布歷史，而develop分支才是用於集成各種功能開發的分支。使用版本號為master上的所有提交打標簽（tag）也很方便。
事實上，Gitflow流程就是圍繞這兩個特點鮮明的分支展開的。
用於功能開發的分支
每一個新功能的開發都應該各自使用獨立的分支。為了備份或便於團隊之間的合作，這種分支也可以被推送到中央倉庫。但是，在創建新的功能開發分支時，父分支應該選擇develop（而不是master）。當功能開發完成時，改動的代碼應該被合並（merge）到develop分支。功能開發永遠不應該直接牽扯到master。
用於發布的分支
一旦develop分支積聚了足夠多的新功能（或者預定的發布日期臨近了），你可以基於develop分支建立一個用於產品發布的分支。這個分支的創建意味著一個發布周期的開始，也意味著本次發布不會再增加新的功能——在這個分支上只能修復bug，做一些文檔工作或者跟發布相關的任務。在一切准備就緒的時候，這個分支會被合並入master，並且用版本號打上標簽。另外，發布分支上的改動還應該合並入develop分支——在發布周期內，develop分支仍然在被使用（一些開發者會把其他功能集成到develop分支）。使用專門的一個分支來為發布做准備的好處是，在一個團隊忙於當前的發布的同時，另一個團隊可以繼續為接下來的一次發布開發新功能。
用於維護的分支
發布後的維護工作或者緊急問題的快速修復也需要使用一個獨立的分支。這是唯一一種可以直接基於master創建的分支。一旦問題被修復了，所做的改動應該被合並入master和develop分支（或者用於當前發布的分支）。在這之後，master上還要使用更新的版本號打好標簽。
創建develop分支
第一步是給默認的master配備一個develop分支。一種簡單的做法是：讓一個開發者在本地建立一個空的develop分支，然後把它推送到服務器。
git branch develop git push -u origin develop
develop分支將包含項目的所有歷史，而master會是一個縮減版本。現在，其他開發者應該克隆（clone）中央倉庫，並且為develop創建一個追蹤分支。
git clone ssh://user@host/path/to/repo.git git checkout -b develop origin/develop
A和B開發新功能
分別開發新功能開始。他們倆各自建立了自己的分支。注意，他們在創建分支時，父分支不能選擇master，而要選擇develop。
git checkout -b some-feature develop
他們倆都在自己的功能開發分支上開展工作。通常就是這種Git三部曲：edit，stage，commit：
git status git add <some-file> git commit
A把他的功能開發好了
在提交過幾次代碼之後，A覺得他的功能做完了。如果她所在的團隊使用“拉拽請求”，此刻便是一個合適的時機——她可以提出一個將她所完成的功能合並入develop分支的請求。要不然，她可以自行將她的代碼合並入本地的develop分支，然後再推送到中央倉庫，像這樣：
git pull origin develop git checkout develop git merge some-feature git push git branch -d some-feature
第一條命令確保了本地的develop分支擁有最新的代碼——這一步必須在將功能代碼合並之前做！注意，新開發的功能代碼永遠不能直接合並入master。必要時，還需要解決在代碼合並過程中的沖突。
A開始准備一次發布
盡管B還在忙著開發他的功能，A卻可以開始准備這個項目的第一次正式發布了。類似於功能開發，她使用了一個新的分支來做產品發布的准備工作。在這一步，發布的版本號也最初確定下來。
git checkout -b release-0.1 develop
這個分支專門用於發布前的准備，包括一些清理工作、全面的測試、文檔的更新以及任何其他的准備工作。它與用於功能開發的分支相似，不同之處在於它是專為產品發布服務的。
一旦A創建了這個分支並把它推向中央倉庫，這次產品發布包含的功能也就固定下來了。任何還處於開發狀態的功能只能等待下一個發布周期。
A完成了發布
一切准備就緒之後，A就要把發布分支合並入master和develop分支，然後再將發布分支刪除。注意，往develop分支的合並是很重要的，因為開發人員可能在發布分支上修復了一些關鍵的問題，而這些修復對於正在開發中的新功能是有益的。再次提醒一下，如果A所在的團隊強調代碼評審（Code Review），此時非常適合提出這樣的請求。
git checkout master git merge release-0.1 git push git checkout develop git merge release-0.1 git push git branch -d release-0.1
發布分支扮演的角色是功能開發（develop）與官方發布（master）之間的一個緩沖。無論什麼時候你把一些東西合並入master，你都應該隨即打上合適的標簽。
git tag -a 0.1 -m"Initial public release" master git push --tags
Git支持鉤子（hook）的功能，也就是說，在代碼倉庫裡某些特定的事件發生的時候，可以執行一些預定義的腳本。因此，一種可行的做法是：在服務器端配置一個鉤子，當你把master推送到中央倉庫或者推送標簽時，Git服務器能為產品發布進行一次自動的構建。
用戶發現了一個bug
當一次發布完成之後，A便回去與B一起開發其他功能了。突然，某個用戶提出抱怨說當前發布的產品裡有一個bug。為了解決這個問題，A（或者B）基於master創建了一個用於維護的分支。她在這個分支上修復了那個bug，然後把改動的代碼直接合並入master。
git checkout -b issue-#001 master # Fix the bug git checkout master git merge issue-#001 git push
跟用於發布的分支一樣，在維護分支上的改動也需要合並入develop分支，這一點是很重要的！因此，小馬務必不能忘了這一步。隨後，她就可以將維護分支刪除。
git checkout develop git merge issue-#001 git push git branch -d issue-#001
上面介紹的是git flow 的詳細過程，但是這樣開發起來會接的是否麻煩，git flow對其進行了封裝簡化。
初始化: git flow init
開始新Feature: git flow feature start MYFEATURE
Publish一個Feature(也就是push到遠程): git flow feature publish MYFEATURE
獲取Publish的Feature: git flow feature pull origin MYFEATURE
完成一個Feature: git flow feature finish MYFEATURE
開始一個Release: git flow release start RELEASE [BASE]
發布Release: git flow release finish RELEASE
別忘了git push --tags
開始一個Hotfix: git flow hotfix start VERSION [BASENAME]
發布一個Hotfix: git flow hotfix finish VERSION
git flow init
這個命令會進行一些默認的配置，可以自動創建上面介紹的所有分支：master、develop、feature、relase、hotfix等分支。
完成後當前所在分支就變成 develop. 任何開發都必須從 develop 開始:
當進行新功能開發的時候：
git flow feature start some_awesome_feature
完成功能開發之後:
git flow feature finish some_awesome_feature
該命令將會把feature/some_awesome_feature合並到develope分支，然後刪除功能(feature)分支。
將一個 feature 分支推到遠程服務器
git flow feature publish some_awesome_feature 或者 git push origin feature/some_awesome_feature
當你的功能點都完成時（需要發布新版本了），就基於develop創建一個發布(release)分支。
git flow release start v0.1.0
當你在完成（finish)一個發布分支時，它會把你所作的修改合並到master分支，同時合並回develop分支，所以，你不需要擔心你的master分支比develop分支更加超前。
當系統出現問題的時候，需要進行緊急修改的時候，就好基於master創建一個維護（hotfix）分支。
git flow hotfix start v0.1.0
當你在完成（finish)一個維護分支時，它會把你所作的修改合並到master分支，同時合並回develop分支。
參考博客：http://www.cnblogs.com/cnblogsfans/p/5075073.html
