規范的Git使用
Git是一個很好的版本管理工具，不過相比於傳統的版本管理工具，學習成本比較高，
實際開發中，如果團隊成員比較多，開發迭代頻繁，對Git的應用比較混亂，會產生很多不必要的沖突或者代碼丟失等。
就像寫代碼需要代碼規范一樣，使用Git進行代碼管理同樣需要一個清晰的流程和規范， Git Flow就是一個被廣泛認可的Git使用最佳實踐。
Git Flow是Vincent Driessen提出的一個分支管理的策略，http://nvie.com/posts/a-successful-git-branching-model/，
應用這個規范可以使得版本庫的演進保持簡潔，主干清晰，各個分支有不同的職責，在很大程度上減少沖突的產生。
Git Flow開發流程
Git Flow通過對分支的管理，實現版本迭代的清晰。
這個流程圖是應用Git Flow的標准流程，可以看到，不同的分支在產品研發和上線的不同階段有不同的作用，扮演了不同的角色。
Git Flow不同分支的角色
結合圖片，簡單介紹一下不同分支的職責。
1.Production分支
這個分支是發布到生產環境的代碼，這個分支只能從其他分支合並，不能在這個分支直接修改。
2.Develop分支
這個分支是主開發分支，包含所有要發布到下一個Release的代碼，這個主要合並自其他分支，比如Feature分支。
3.Feature分支
Feature 分支主要用來開發一個新的功能，一旦開發完成，合並回Develop分支，並且進入下一個Release，Feature分支可以選擇刪除或者保留。
4.Release分支
當需要發布一個新Release的時候，基於Develop分支創建一個Release分支，Release分支在測試過程中可能會修改，完成Release后，合並到Master和Develop分支。
5.Hotfix分支
當在Production發現新的Bug時候，需要創建一個Hotfix分支, 完成Hotfix后，合並回Master和Develop分支，所以Hotfix的改動會進入下一個Release。
Git Flow使用原則
- Master分支是線上穩定分支，Release通常用作測試分支，Develop分支是開發應用的主分支
- 所有的功能開發都在Feature分支進行，然后合並到Develop分支
- Release分支發布后出現問題，直接在Release分支修改，避免Develop分支代碼污染
Git Flow分支協作最佳實踐
我們在應用Git Flow的時候，也遇到了一些問題，比如開發結束后，在develop分支進行merge開發分支操作，出現沖突如果不能很好的解決，容易對develop分支的代碼造成污染。
下面是實際開發中使用的流程，在Feature分支上合並develop代碼，然后合並到develop分支上，流程更加清晰，沖突優先在開發分支解決。
一個開發人員典型的提交流程：
//新建分支 git checkout develop git pull origin develop git checkout -b myfeature //在分支上開發 git add *** git commit -m "*****" //在分支開發過程中合並develop分支到本分支（先把自己的工作commit到本地） git checkout develop git pull origin develop git checkout myfeature git merge develop （如果沒有沖突，就繼續開發，如果有沖突，執行下面過程） 首先在本地解決沖突，再把沖突解決commit git add *** git commit -m "*****" //在分支開發結束，需要將本分支合並到develop分支（先把自己的工作commit到本地） git checkout develop git pull origin develop git merge myfeature （如果沒有沖突，就推送到遠程） git push origin develop （如果有沖突，則解決沖突，再commit，並推送到遠程：） git add *** git commit -m "*****" git push origin develop
應用Git Flow的目的是更好的進行版本管理和持續集成，有些細節並不一定要遵循這個模型，可以根據團隊規模進行簡單的調整，適合的才是最好的。