写给此时凌乱的你
git 现时代做前端必备的技能了。只会简单 add commit 是可以临时应付一下工作，如果进行稍微有点规模的项目，多项功能并行开发，多个bug 都必须同时修复上线，你会发现你的工作流越来越乱。
俗话说：无规矩不成方圆。所以在做开发时候有一套团队的 git flow 还是比较重要的！ 近期我就在做这样的事，如果你也在做，不妨一起聊聊，不同的角度会碰撞出更漂酿的火花。
进入主题：
今天重点要解决的是两个问题： 1. 代码分支管理 2. 提交流程
简单目录：
一： 命名规范
二： 分支由来
三： 代码推送 （ feature
四： 代码推送 （ hotfix
五：git 命令
一：先说说我们分支命名规范：（如下图）。 是在每个成员心中埋下一个伏笔， 以后就可以根据命名，来判断一个分支是用来开发新功能的，还是在修改 bug。
二： 命名规范有了，接下来聊聊每一分支的由来：
master 是石头缝里蹦出来的
develop 是 master 的长子
feature / coding01 每次新功能开发都是从由 develop 切出来的新分支
hotfix / coding01 每次修改线上 bug 都直接从 master 切一个新分支
三： 功能开发分支 （ feature / coding01 ）代码推送流程：
本地多人开发，必须都把 topic 分支代码合并到 feature 分支
然后推送 test / dev 进行发布测试，
测试 ok 之后，合并到 develop 分支等待上线。
上线之时，负责人合并 develop 代码到 master 上线
四： Bug 修复
修复完 Bug ，合并到 test / dev 测试
测试完成后直接推送到 master 发布
并同步给 develop ，（为了在开发新功能到时候，不用在出现老 Bug）
五： git 命令行
