Gitflow工作流
1. 在码云上创建仓库，克隆仓库地址
2. 找个空的文件夹 git Bash here --->关联仓库的系列操作（http://blog.****.net/embrace924/article/details/78189208 具体操作）
3.在master的分支上创建develop分支，切换到develop分支
4.设置develop的上游分支（更改代码后推送的分支地址,一般就是自己的分支名字）
然后就可以推送更改后的代码了
5.在develop上创建一个文件
仓库里面就有了之前的提交
在develop
分支上新建功能分支feature-login分支与feature-pay分支
同理切换到develop的子分支，设置上游分支，就可以推送更改后的代码
项目网络图查看记录
如何合并develop 和feature-login
合并后 因为没有冲突 会自动提交
然后你只需要推送一次 就可以再仓库中看到合并后的信息
develop项目网络图
新建预发布分支release 准备对现有功能出一个发布版
对次发布版进行测试和bug修复等等操作后提交可以发布的版本
这里合并采用了rabase 与merge有点差别 后面解释
a分支上有1-2进度，在2的时候创建了b分支，然后分别开始开发，到了一定时候a分支处于4，b分株处于z,需要将a 合并到b
使用merge 如果 a 合并到b 就是z 后面直线上直接跟 p 就会发起一个合并的提交生成p的提交历史，p就是合并完成的内容
如果 b 合并到a 就是4 后面直线上直接跟 p
使用rebase 如果 a 合并到b 的时候4后面的路径变成了x-y-z 且 x-y-z会整体往后移动到4 斜下方的位子
如果 b 合并到a 就是4 后面直线上直接跟x-y-z 看不出曾经有分支然后合并到一起
此次用的是rebase 就没有看出release/1.0的创建出的分支路径 而是合并后直接归属于master
login的功能做完后不光要合并到master上发布 也要合并会develop 因为后面的功能开发可能会依据这个功能
再login 合并回来之前另外的pay团队完成了pay的功能 已经合并到了develop上 这也是优点所在 相互不干扰
继续开发过程中
如果用户发现bug 这边在解决bug的时候会新开一个分支 fxbug-1.0 在里面解决bug后再合并到master和develop上