目前在工作使用到类似gitflow的工作流；总结出实际操作中，可能会遇到的问题以及解决方法
gitflow工作流分支
develop 分支（主分支） 开发分支master 分支 （主分支） 测试版本修复好bug合并到这里并打上tag 生产环境版本管理分支release 分支 （主分支） 测试版本分支（用于测试环境修复bug 不容许新增需求）feature分支 新任务开发分支（用完即删）hotfix分支 修复发布到master分支的bug，修复完成后用cherry-pick合并到master和develop分支
gitflow工作流流程
从master创建一个分支develop从develop创建一个分支release从develop创建分支 feature当feature完成后，会被合并到develop 分支当release分支测试完成后，合并到develop和master如果master检测到问题，则从master位置创建分支hotfix一旦hotfix完成后，会被合并到develop及masterfe分支
问题点：
release阶段时间过长 release时间过长导致release上面修复bug的周期过长，导致develop分支上的bug没有长时间得到合并修复 解决方案: 每次release修复完bug都merge到develop分支release阶段develop分支上的同模块的版本内容发生变化（eg： develop分支上订单详情页面删除了总数量的统计， release分支上的版本需要这个功能）这个时候合并release分支到develop会覆盖，develop上的订单详情版本 解决方案: 需要合并之后的，手动更改develop上的版本内容；之后合并release到develop不会出现该问题hotfix分支上的修改的内容需要同时在master，develop， hotfix分支进行修改，有些同学使用切换到每个分支去分别修改 解决方案： 推荐使用cherry-pick去合并单个或者多个commit
