前言
众所周知，Git的强大之处在于十分方便与团队合作中的代码管理，那么在一个团队中，什么样的工作流是合适的？需要维护多少个分支以及怎样去维护才是合适的？带着这些问题，让我们来看一下Git的工作流。最近项目需要迁移，之前的分支管理比较混乱，所以趁着迁移，规范分支的管理。
概况
目前Git主要有三种使用广泛的工作流
- Git flow
- Github flow
- Gitlab flow 这里就不一一介绍了，参考阮一峰的博客。
接下来看一篇我觉得比较好的Git分支模型的文章，传送门。
这位仁兄给出了一个模型图。
这个模型里面共有五个分支
- master
- develop
- Feature branches
- Release branches
- Hotfix branches
看看原文的说法：
The main branches
At the core, the development model is greatly inspired by existing models out there. The central repo holds two main branches with an infinite lifetime:
- master
- develop
master和develop分支是两个主要的分支，这两个分支都拥有较长的生命周期。每个Git用户都应熟悉原始主分支。 与主分支并行，另一个分支称为develop。我们将origin / master视为主要分支，其中HEAD的源代码始终反映生产就绪状态。 我们认为origin / develop是主要分支，其中HEAD的源代码始终反映了下一版本中最新交付的开发更改的状态。 有些人称之为“整合分支”。
master分支和develop分支的区别在于master相对比较稳定，代表的是生产就绪状态，develop分支代表的是最新的更改状态。新的更改需要累积，等到到达一个里程碑的时候就会合并到主分支。这代表着一个版本的迭代。合并到master分支上意味着是最新的稳定版。
Supporting branches
Next to the main branches master and develop, our development model uses a variety of supporting branches to aid parallel development between team members, ease tracking of features, prepare for production releases and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited life time, since they will be removed eventually.
The different types of branches we may use are:
- Feature branches
- Release branches
- Hotfix branches
三个支持分支，特性分支，版本释放分支，热修复分支。
特性分支：特性分支从develop分支检出，合并回develop分支。特性分支包含需要开发的新的特性，或者是下一版本的一些新特性。
版本释放分支：开发到了一定的稳定点，可以进行发布的时候，就可以新建一个释放分支。
热修复分支：这是项目在项目出现问题，需要紧急修复的，需要新建热修复分支。
牛刀小试
创建一个新的特性分支，从develop开发分支检出.
$ git checkout -b myfeature develop
Switched to a new branch "myfeature"
Incorporating a finished feature on develop
Finished features may be merged into the develop branch to definitely add them to the upcoming release:
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop
–no-ff：不使用fast-forward方式合并，保留分支的commit历史。
两种提交历史比较：
总结
本来打算翻译一番这个文章的，但是这篇文章看下来应该还是通俗易懂的，就不去翻译了，有兴趣的可以去看原文。
