GIt Flow（一种git开发规范）

一、前言

git flow是团队通过git进行合作的一种对代码进行管理的规范，主要作用是保证协同工作的顺利进行和代码的正常运行。

二、概括

规范中代码分为两大分支（dev、master），master主要是当前开发的app版本，一般用来投入生产，dev则是开发的版本。
规范中对其他分支的分类主要分为三种对行功能的开发一般用feature-作为分支名，对bug的修复一般用hotfix- / fixbug-作为分支名，当功能开发完到了测试和预发布环节一般用pre-release- / release-作为分支名。
规范中对分支的合并也有明确的要求，首先不是所有人都被允许执行合并，只有管理者允许合并，一般开发者只允许进行提交，这是一种保护代码的机制，在github中可以通过Gitlab来进行。而对对应分支的合并也有要求，feature-、hotfix-* / fixbug-分支一般只合并到dev分支，当开发完成，进入测试环节有pre-release- / release-*这个分支测试完成分别合并到两个分支。

三、简单来说

• fixbug-*用来修复一下大部分小bug
• hotfix-*一般用来修复一些紧急bug（自认为一般是下班时间突然让改代码的bug才算紧急bug，很着急的样子）
• feature-*用来开发新功能
• release-*为一般测试分支有bug直接在上面改也行，最后合入dev
• pre-release-从dev合并到master分支之前的预发布分支，用于最后测试，一般是feature-的新功能开发后用
• master一般不拉分支，从dev拉
• 99%的情况禁止拉master分支、99%的情况禁止拉master分支、99%的情况禁止拉master分支、99%的情况禁止拉master分支、99%的情况禁止拉master分支、99%的情况禁止拉master分支、99%的情况禁止拉master分支

四、其他

合并分支有两种模式fast forward，不生成单独的合并节点；none fast-forword，会生成单独节点。前者不利于保持commit信息的清晰，也不利于以后的回滚，建议总是采用后者（即使用--no-ff参数）。只要发生合并，就要有一个单独的合并节点。