什么？？？git还需要区分分支？花里胡哨的，我管你什么分支，master一把梭。程序猿手册开篇第一句：“代码和人能跑一个就行”，这不是跑起来了？前段时间，从后端大佬那里偷了一手gitFlow分支管理流程，翻了掘金，发现大部分贴子都是之前的，于是决定写下此文档。朋友，答应我，别再master一把梭了，好吗？
优势
首先让你的git分支清晰易懂，然后所有的版本都在预发布状态，完全可以在一个版本还未上线时，开始开发下一个版本，而不用担心代码混乱，多人协同开发、敏捷开发必备。
分支部分
感觉每个公司都有不同的gitFlow，下面的可能和其他公司的有所出入
master
长期分分支，稳定版本分支，只有release分支和hotfix分支能合并至此分支，版本清晰。
dev
长期分支，开发分支，只能合并至master分支，不能随意往dev分支上提交代码，上面的每次提交都是一个功能的完成。
feature
短期分支，功能分支，从dev拉取，开发完成后合并至dev，并关闭分支。每个功能对应不同的feature。
release
短期分支，待发布分支，从dev拉取，在此分支上面进行测试以及bug的修复，版本发布后后合并至dev与master分支。
hotfix
短期分支，紧急分支，从master上面拉取，修复完成后合并至master，并关闭分支。
技术有限，如有错误请大佬指正，最后问一句：“你们相信属相不和的问题？”
