图解git flow开发流程
转载至：图解git flow开发流程 - 知乎 (zhihu.com)
在实际生产开发的过程中，如果每个人都随意的创建分支，随意的提交commit，必将导致整个git仓库非常的混乱，不易于团队协作。Vincent Driessen 同学为了解决这个问题提出了A Successful Git Branching Model，最后形成了业内普遍采用的git 工作流程，大家都在约定的流程内使用git，使得团队协作效率大大提高
下面是git flow的工作流程图：
Git Flow 的常用分支
- 生产分支（master）
Master分支是仓库的主分支，这个分支包含最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改
- 补丁分支（hotfix）
当我们在生产环境发现新的Bug时候，我们需要基于master分支创建一个Hotfix分支，然后在Hotfix分支上修复bug，完成Hotfix后，我们要把hotfix分支合并回Master和Develop分支
- 发布分支（release)
当你需要发布一个新功能的时候，要基于Develop分支创建一个Release分支，在Release分支测试并修复bug，完成release后，把release合并到master和develop分支
- 开发分支（develop）
这个分支是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支
- 功能分支（feature）
feature分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release
接下来我们讲下git flow的具体使用细节：
当我们新建git仓库之后，默认会创建一个主分支也就是master分支，由于master分支是用于发布生产环境，所有必须保证master上代码的稳定性，所以我们不能直接在master分支上修改提交。我们要基于master分支创建一个develop分支，develop分支用于保存开发好的相对稳定的功能，master分支和develop分支是仓库的常驻分支，一直会保留在仓库中
当新的开发任务来了之后，就要编写代码了，我们尽量不要在develop分支上写代码，要保证develop分支的相对稳定，所以这时我要就要基于develop 分支创建一个临时的开发分支，然后在开发分支上编写代码，等功能开发完之后我们再把开发分支合并到develop上
新功能合并到develop分支之后，我们想把新功能发布到生产环境，首先基于develop分支创建release分支，然后在release分支测试完成之后，把release分别合并到master分支和develop分支
release分支合并到master分支之后，在master分支上打标签用于发布：
我们把代码发布到了生产环境，用户在使用的时候给我们反馈了一个bug，这时我们需要基于master分支创建一个hotfix 分支，用于修复bug，bug修好之后，把hotfix 分支分别合并到master分支和develop分支
