一个值得参考的Git分支管理模型如下：
master 生产主分支，发布到生产环境使用这个分支，由hotfix或者release分支合并过来，不直接提交代码。
release 预发布分支, 基于feature分支合并到develop之后 , 从develop分支克隆，测试完成后合并到master并tag打上版本号，同时也合并到develop。
develop 主开发分支, 基于master分支克隆，由feature分支合并过来，一般不直接提交代码。
feature 功能开发分支 , 基于develop分支克隆 , 主要用于新需求新功能的开发，可能同时存在多个。
hotfix 补丁分支, 基于master分支克隆 , 主要用于对线上的版本进行BUG修复，完成后合并到master分支和develop分支。
除了分支管理模型之外，对于分支的命名也需要值得注意，尽量做到“见名知意”的效果。
比如：
1.功能分支可以命名为feature.<author>.<YYYYmmdd>，表示是谁在什么时间新建的分支，当然也可以将功能体现在分支名称中。
2.修复问题分支可以命名为hotfix.<BUG_NUMBER>.<YYYYmmdd>，表示在什么时间修复的指定BUG号。
【参考】
https://segmentfault.com/a/1190000020280903 图文讲解，团队开发中的Git最佳实践
https://www.cnblogs.com/Irving/p/5146738.html Git: 教你如何在Commit时有话可说
https://ihower.tw/blog/archives/3843 使用 git rebase 避免無謂的 merge