GitFlow工作流使用总结

1、开发新功能从dev拉feature；
2、完成功能合并feature到dev，然后拉出release分支；
3、release分支发布测试环境；
4、在release上修复bug；
5、完成release，代码合并到dev、master；
6、在预生产发布master；
7、预生产的Bug，从master拉出hotifx解决；
8、解决完bug，合并hotfix到dev、master；
9、在发布生产在master；
10、生产的Bug，从master拉出hotifx解决；
11、解决完bug，合并hotfix到dev、master；
12、在master上打tag，Tag名称是版本号，信息是这个版本做的内容。打完Tag，确认下有推送成功，版本就结束啦。

另：线上问题的处理，同10、11点。

hotfix，是在最新的版本上标注，有时候bug可能是之前的版本遗留的，但是在当前版本也会有，所以还是以最新版本来标注，如1.0的bug，到了最新的1.4版本才发现，1.4也合到master，那么hotfix应该是1.4.h1，而不是1.0.h1

-----

Update 2017年12月18日

GitFlow是可以跨团队的，大家都是用gitflow的流程来版本控制；

不同Git规范是不兼容的，比如我用GitFlow，而你用基于主干或者开发分支的开发，那么就会有冲突。