gitflow工作流 在实际使用中遇到的一些问题

目前在工作使用到类似gitflow的工作流；总结出实际操作中，可能会遇到的问题以及解决方法

gitflow工作流分支

1. develop 分支（主分支） 开发分支
2. master 分支 （主分支） 测试版本修复好bug合并到这里并打上tag 生产环境版本管理分支
3. release 分支 （主分支） 测试版本分支（用于测试环境修复bug 不容许新增需求）
4. feature分支 新任务开发分支（用完即删）
5. hotfix分支 修复发布到master分支的bug，修复完成后用cherry-pick合并到master和develop分支

gitflow工作流流程

1. 从master创建一个分支develop
2. 从develop创建一个分支release
3. 从develop创建分支 feature
4. 当feature完成后，会被合并到develop 分支
5. 当release分支测试完成后，合并到develop和master
6. 如果master检测到问题，则从master位置创建分支hotfix
7. 一旦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