崔同学说逃避解决不了问题，那就勇敢面对。
两年前看过阮一峰老师的文章，认识了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分支，也是临时的分支，用完之后可以删掉；