git分支策略规范

Master分支
此分支用来放置上线版本的内容，在开发中，此分支是别的分支的基点，此分支往往设置为保护分支，只允许管理人员或分支创建者去合并Hotfix分支和Release分支，绝不允许直接push代码到此分支。

Develop分支
此分支来源于Master分支，用来放置开发期间的内容，可以认为此分支出来的版本是开发版。在实际开发中，此分支往往也设置为保护分支，只允许管理人员把功能分支(Feature)、Bug修复分支(Hotfix)、正式版分支(Release)合并进来，也不允许直接提交代码到此分支。

下面是各种场合的分支创建策略：
Feature分支
当接到一个新的功能模块开发任务后，我们要在Develop分支Master分支上创建新的功能分支(Feature)，分支的名称最好以功能来命名，这样便于后续的任务识别。有关联的模块最好放置在同一个分支，便于调用。另外，分支可以由多个程序员来维护，但是，由一个来创建，然后push到远程仓库，同分支下别的程序员pull分支内容下来，然后一起协同开发。

此功能开发完了，怎么处理？
功能开发完了，不仅仅是功能实现了，还必须要保证单元测试了且没有问题，业务逻辑没有问题，本功能测试没有问题，这时候就可以向管理者发布一个合并到Develop分支Master分支的请求，管理人员收到合并请求后，最好要进行代码的审核，没有问题了再合并，合并完成后，就可以删除原功能模块分支，开发团队完成了此功能的开发。

Release分支
当设计的功能完整后，需要给客户使用了，这时候需要对项目进行完整的功能测试，这时候，需要在Develop分支上新建一个正式版分支(Release)，表示正式版的功能就是目前开发版的完整功能，然后开发版可以继续添加新功能，但是，在目前正式版中是没有的，要下个版本才提供。在正式版上要对项目进行严格的测试，发现Bug，直接在此分支上解决。直到测试发现的BUG都解决，没有问题了，相关负责人就向Master分支管理员发送合并到Master的请求，Master分支管理员收到请求后，经审核在合并，然后在此基础上编译出一个正式版运行项目，部署到相关的生产环境中。另外，要把此分支并入到Develop分支中，以解决掉Develop分支中代码的Bug。

Hotfix分支
正式版发布后，用户在使用中发现Bug，怎么处理？这时候，我们要在Master分支上去创建Hotfix分支，然后解决Bug，解决完后再并入到Master分支以及Develop分支。