本文基于这样一个场景：有多个新功能并行开发，按先后顺序上线，但是偶尔会出现正在测试的版本暂停上线，另外一个紧急功能需要优先上线。本文分享一个用git分支来管理这样的场景。
本文基于：https://nvie.com/posts/a-successful-git-branching-model/
这边文章对于大部分场景都能很好的应用，大家可以好好阅读下。可以在这个基础上扩展后来适配自己的场景。下面是我基于上面提到的场景进行修改后的方案：
主要分支
中央仓库中有两个长期的分支：
- master
- develop
master 用作生产分支，里面的代码是准备部署到生产环境的。
develop 是可交付的开发代码，也可以看成是用于集成分支，一个功能完善的分支，此分支的代码需要推送的开发环境进行功能验证。
当 develop 分支中的代码足够稳定的时候，就将改动合并到 master 分支，同时打上一个标签，标签的名称为发布的版本号。
辅助分支
通过辅助分支来帮助并行开发，和主要分支不同，这些分支的生命周期是有限的：
- feature
- release
- hotfix
- emergency
feature（新特性分支）
feature分支可能从 develop 分支分出，最终 必须 合并回 develop ，或者放弃。
特性分支用于开发一次发布所需要的功能。最终会合并回 develop （当功能开发完毕的时候），或者放弃（如果最终决定不开发这个特性）。
不建议直接再feature分支开发，组员建立自己的本地分支，开发完成提交merge request到feature，由负责人对代码进行review，通过后合并到feature分支。
可以同时存在多个feature，只有一个feature发布上线后，另外一个feature才能合并到develop，如果需要提前上线，需要走emergency分支。
release（发布分支）
release分支可以从 develop 分出，最终 必须 合并 master 。发布分支以 release-* 的方式命名。
发布分支为新的发布版本做准备，用于部署到测试环境进行测试，测试通过后可以发布上线。当可以发布上线时，将代码合并到master。
在代码的功能验证通过的时候，可以测试的时候从 develop 分支分出release分支。这时要确保此次发布包括的特性都已经合并到 develop 分支了（同时，为下一版发布准备的特性不能合并到 develop 分支，必须等待发布上线后才能合并）。
hotfix(紧急修复分支)
从 master 分出， 必须 合并回 develop 和 master 。分支名以 hotfix-* 开头。
紧急修复分支和发布分支很像，只不过它们是意料之外的。如果生产系统里有一个紧急的bug，必须马上修复的话，我们就从 master 里分出一个紧急修复分支。
这样，某个人修复紧急bug的同时，团队其他成员可以继续在feature 分支上开发。
完成bug修复后需要部署到临时测试环境。测试通过后，发布上线，经代码合并回master和develop。
emergency(紧急上线分支)
从 需要紧急上线的feature分出， 必须 合并回 develop 和 master 。分支名以 emergency -* 开头。
紧急上线分支和发布分支很像，只不过它们是意料之外的。如果计划外的新特性需要提前上线，可以将feature分支的代码提交到emergency，然后部署到临时测试环境进行测试。测试完成部署到生产时，需要将代码合并回 develop 和 master。
这样，某个新功能紧急上线的同时，团队其他成员可以继续在其它feature 分支上开发，或者在release进行另外版本的测试。
来源：https://www.cnblogs.com/lilinwei340/p/12401618.html