共计 1212 个字符，预计需要花费 4 分钟才能阅读完成。
为了更好地治理目前公司内的源码版本，让大家更好的协同工作，前阵子看了不少对于 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 批改）整个流程能够下图展现