git作为源码管理工具出于流行趋势。这里和大家一起分享下我们是如何用git的分支(branch)功能管理不同规模的项目
　　小型项目
　　推荐工具：TortoiseGit
　　开发阶段（第一版上线前）：2个分支 develop和master
　　由于是项目参与人员不多，基本上很少会有不同角色的人员出现职责冲突，需求变更也不会很繁冗。这种情况值我们只需要主要功能分支。
　　其中develop负责开发版本，master相当于预上线版本。
　　develop过程如果出现代码冲突，手工merge好。
　　开发阶段（第一版上线后）：3个分支 develop、master、hotfix
　　多处于来的hotfix用于紧急上线（bug，新需求等）。hotfix基于master，因为develop已经越走越远，基于develop的hotfix会将带上一些当前不想上线的新功能。
　　hotfix完成后hotfix要merge到master上，因为线上不管何种情况都是master版本。qa完成测试并且上线后要将master版本merge到develop避免hotfix的修改在develop中丢失。
　　维护阶段(停止常规开发)：2个分支 master、hotfix。
　　这个阶段相当于针对上线版本的各种打补丁了。
　　中型项目
　　推荐工具： sourcetree
　　开发阶段（第一版上线前）：3个分支 feature、develop和master
　　相对于小型项目多了feature分支的概念。feature分支基于develop分支，当功能开发完成后merge回develop。

　　这样做的好处是将develop分支从小型项目中去中心化。举个例子，因为是中型项目，我们可能有5 6个在并行开发，如果这个过程中客户说某个功能我们不要了，我们可以很轻松的丢掉某个feature分支而不必污染develop。
　　但是如果是开发时间很久的feature分支，很可能会因为不定时的merge develop或者需求的不断变更等导致当前分支的commit比较肮脏。所以对于feature分析的力度要控制好。
　　如图所示：

　　开发阶段（第一版上线后）：4个分支 feature、develop、master和hotfix
　　和上面小心项目一样 hotfix基于master版本。
　　维护阶段(停止常规开发)： 和小型项目一样