前言：之前分到一个项目，老是不知道在开发时应该将哪个分支做为基分支，开发完成合并时又不知道以哪个分支为基分支做合并，每次老是一头雾水，还总嘚问其他开发，所以这次来好好梳理一下：
①各分支介绍
②各分支在不同场景如何配合使用
有参考：https://blog.csdn.net/hherima/article/details/50386011
先放一个git分支模型，这是Vincent Driessen设计的：
各分支介绍：
Master:作为当前项目版本控制最稳定的分支，和develop作为两大主分支之一，分支的生命周期与项目相同。
在哪些情况下会用到Master分支：
- 第一次创建develop分支时，master会作为develop分支的源分支。
- 项目的新功能发布时，Release分支会合并到Master分支。
- 线上项目出现bug时，以master分支作为源分支创建hotfix分支。
- hotfix的代码修复成功后，合并代码到master分支。
Develop：作为开发的主分支，生命周期与项目相同。
在哪些情况下会用到Develop分支：
- 项目有一个新的功能点需要添加，这时，以develop分支作为源分支创建feature分支。
- feature分支开发完成，将代码合并到develop分支。
- hotfix分支bug修复完成会合并到develop分支。
- 在发布之前，需要为develop分支做一个版本或者对代码进行一些小的修改，那么以develop分支作为源分支创建release分支。
- 新功能即将发布，release分支合并到develop。
Feature：通常作为一个新功能特有的分支，一旦feature分支合并到develop分支，代表该功能编码完成，feature便可删除。
Release：发布分支，为本次发布制定版本，顺便修复一些分支代码存在的bug，项目一旦发布，release分支生命周期终止。
Hotfix:bug修复分支，解决线上一些问题，当问题修复且合并到master及develop，hotfix分支即可删除。
上述对各分支的描述仅是我对这个模型的理解，个人认为非常合理。但是与我们团队使用的分支模型还是有一些异同点。
异同点在于：
Vincent Driessen的git分支模型：
团队的git分支模型：
结构的不同会带来结果的不同，那么来看看实际场景两种模型是怎么应对的吧：
①上一个Feature还未发布，本次的Feature会依赖上次Feture分支的代码
Vincent Driessen的git分支模型：
不受影响，新的Feature分支还是从Develop分支拉取正常开发，合并时合并到Develop分支。
团队的git分支模型：
因为之前未发布的代码在Release上，所以本次的Feature分支的代码拉取需从Release分支，而在合并时被合并分支也已Release分支为源分支。
这里的问题我觉得是：
各分支的职责不太清晰，Develop不太像正在开发的分支，而Release也不太像即将发布的分支，它有成为正在开发的分支的可能。
②有两个Feature未发布代码分布在两个Release中，并且本次Feature会依赖两个Feature的diamante。
Vincent Driessen的git分支模型：
不受影响，不管几次Feature未发布，最新的代码都在Develop中，依然正常拉取开发，合并时合并到Develop分支。
团队的git分支模型：
无法工作，只能将未发布的Release分支合并到Develop分支中，然后从Develop分支中拉取代码。
带来的问题是：
同时将多个分支代码合并到一个分支中，会有较大的工作量。
还有，就算每次的Release分支的代码都会更新到Develop当中，但是我还是感觉从Release到Develop这样的做法会模糊各分支的职责。
最后，也许是我对团队的git管理方式还太过片面，很多方面没有了解到位，后面还需做更多功课，做到深刻理解其形成背景。
