为了更好地治理目前公司内的源码版本，让大家更好的协同工作，前阵子看了不少对于git版本治理的文章，总结除了一个绝对简略的治理标准，并在实际一段时间后，进行了调整。最终版如下：
1.master分支
寄存的应该是随时可供在生产环境中部署的代码
当开发流动告一段落，产生了一份新的可供部署的代码时，master分支上的代码会被更新。同时，每一次更新，都有对应的版本号标签（TAG）。
分支命名：master
该分支，由管理员负责保护，其它人只有拉取权限。来自于release分支的合并，供发版应用
生命周期：随同着整个我的项目的生命周期，我的项目完结时完结。
2.develop分支
develop分支是每次迭代版本的共有开发分支，从最新的master分支派生（管理员操作）
当develop分支上的代码已实现了软件需要说明书中所有的性能，派生出release分支（管理员操作）
分支命名：dev-版本号
该分支，由开发人员在各自的feature分支开发实现后，合并至该分支。
生命周期：一个阶段性能开发开始到本阶段完结
3.release分支
从develop分支派生（管理员操作）
测试环境中呈现的bug，对立在该分支下进行批改，并推送至近程分支。批改内容必须合并回develop分支和master分支。
分支命名常规：release-版本号
生命周期：一个阶段性能开发完结开始，实现阶段功能测试并修复所有发现bug，合并会develop分支完结。
4.feature分支
在开发一项新的软件性能的时候应用，这个分支上的代码变更最终合并回develop分支
分支命名常规：feature-姓名全拼-分支阐明-日期 / feature-分支阐明-日期
例：接到一个开发对于cc视频点播替换的工作，你须要从develop分支拉出一个分支，并命名为：release-yuruixin-ccVideo-20171117。而后在该分支下进行开发，开发完结，将该分支合并至develop分支（此时的代码必须为可运行的，不能影响到别人），合并实现删掉该个性分支。
开发人员的每一个新性能开发都应该在该类分支下进行。
生命周期：开发一个新性能开始，实现新性能开发并合并回develop分支完结。
5.hotfixes分支
在master分支发现bug时，在master的分支上派生出一个hotfixes分支，批改实现后，合并至master分支以及develop分支，合并实现，删除该hotfixes分支。
分支命名常规：hotfixes-姓名全拼-分支阐明-日期
示例：hotfixes-yuruixin-cclivebug-20171117
生命周期：发现master分支bug开始，实现master分支bug完结。
综上，开发人员须要操作的分支如下：
feature分支 （开发应用）release分支 （测试中呈现的bug批改）hotfixes分支 （master中呈现的bug批改）整个流程能够下图展现