分支模型by 程序亦非猿 2016.4.6
这又是一篇我在公司分享的，想制定一下Git的规范，有兴趣的可以看看~
上一篇在这里
每个项目必须要有master、develop分支。
每个开发人员拥有一个自己的分支，如yfy、chz。
master 分支
master 分支只能存在release版本的代码，并需要对每个release打对应的tag。
develop 分支
develop 由master分支检出，它作用主要是日常开发合并代码，并与master分支做交互。
当参与开发的人员较多时，可指定一个人管理develop分支，专门负责合并代码，便于管理，避免多人同时使用develop分支而出现问题。
另外当功能开发完毕后，代码合并入develop分支，测试完成通过后，merge到master分支，并在master上打tag。
开发人员自己的分支
开发人员自己的分支，由develop分支检出，是自己负责的功能分支的上游
Feature （新需求开发）
当有新需求需要开发时：
- 每个开发人员在自己的分支上检出一个新的feature分支，如在
czn上检出feature_search分支 - 在新的feature分支上进行开发
- 新功能开发完毕后合并到自己的分支
- 所有人员的分支合并到develop分支，并进行测试
- 测试通过后合并到master，并打tag
Hotfix （紧急修复bug）
当有紧急bug需要修复时
- 从master 拉分支hotfix_xxx
- 修复完毕后合并到develop分支
- 测试完毕后合并到master分支，并打tag
分支模型已经工作流程大约如图所示：
gitflow是git的一个辅助工具，可以简化我们新建分支，合并分支，删除分支的操作，也可以减少人工误操作而出错的概率
举个例子：
新功能能开发，使用gitflow之前：
git checkout yfy
git checkout -b feature_search
...developing...
git checkout yfy
git merge feature_search
git branch -d feature_search使用gitflow之后：
git flow feature start search
...developing...
git flow feature finish search是不是省去了很多繁琐的操作？
gitflow 的功能不止如此~
gitflow虽好，但是考虑到大家刚开始使用git，需要熟悉git以及git命令，所以它现在不是强制的，如果有兴趣或者你也懒得敲那么多命令的话，建议看看 git-flow 备忘清单
最后PS: 事实上git最开始是没有gitflow的，它是用户实际经验的总结，so，希望我们团队最终能拥有最适合我们自己的gitflowgitf
规范是死的，人是活的，上诉所说都是比较理想化的，实际情况可能更加复杂，大家可以根据实际情况调整。
如果有疑问或更好的建议，欢迎反馈~~~
随时随地看视频
