崔同學說逃避解決不了問題，那就勇敢面對。
兩年前看過阮一峰老師的文章，認識了git分支管理策略，但那時項目代碼是用SVN管理，接觸git是因為github，github一直停留在單人單分支的階段。后來換工作了必須用git，發現分支管理的強大之處，所以寫一篇記錄一下。
如何管理好git分支，國外的nvie發表了博客 a-successful-git-branching-model, 文章講解了他是如何讓自己的Git倉庫保持整潔，阮一峰老師說的也是基于nvie的思想，推薦大家看完阮老師的文章，好好感悟感悟，然后在再來糾正一下我的理解，哈哈。
基本流程一張圖足以說明；
有人說這張圖要橫著看，我就得并沒有什么影響，豎著看吧。下面就基于這張圖，針對項目的實際情況，分析每一個分支的意義；
首頁，這張圖從上往下是時間軸，代表項目進展或者代碼的迭代，這個沒問題。
分支作用：
master分支
master永遠保持線上的穩定版本，不要在master上做開發；develop分支
develop是開發分支，一般一個工程只有一個develop分支，在多人多項目同時開發時，它是一條大河，一般不會直接在develop分支上寫代碼，都是從feature分支合并過來；feature分支
feature分支不是單獨的一個分支，是一個個的分支，根據需求而定了，它們從develop分支check出來，是一條一條的小溪，我等小弟就是在這樣的分支上coding，等一個功能開發的差不多了，develop分支就把它合并過去，這就是溪水流入大河的過程；等功能開發完畢，它們就沒用了，可以當做垃圾清理掉；release分支
release分支是上線前的預發布分支，是臨時分支，這個分支是從develop分支check而來，它是記錄即將發版的代碼，在release里可以做上線前的bug修改工作，但是不能再增加新的功能，此時develop分支可以繼續開發新的功能，release最終還要合到master和develope分支，因為在release中有可能改過bug；hotfixes分支
hotfixes聽著像是熱修復，其實就是線上bug修改分支，他從master分支check代碼，修改完再合并到master和develop分支，也是臨時的分支，用完之后可以刪掉；
