Centralized 工作流
集中式工作流像 Subversion 一样，集中式工作流以中央仓库作为项目所有修改的单点实体
图例
功能工作流
这种工作流关注功能开发，不直接往master提交代码保证它是稳定并且干净的，而是从master拉取feature分支进行功能开发，团队成员根据分工拉取不同的功能分支来进行不同的功能开发，这样就可以完全隔离开每个人的工作。当功能开发完成后，会向master分支发起Pull Request，只有审核通过的代码才真正允许合入master
图例
Git Flow工作流
该种工作流会相对复杂一点，但非常适合用来管理大型项目的发布和维护。贯穿整个开发周期，master和develop分支是一直存在的。
图解
分支分配
master
master分支可以被视为稳定的分支，一般不允许直接往master分支提交代码，只允许往这个分支发起merge request，只允许release分支和hotfix分支进行合流
develop
develop分支是相对稳定的分支，用于日常开发，包括代码优化、功能性开发。
feature
feature分支从develop分支拉取，特性开发会在其上进行，开发完毕合后并到develop分支。
release
release分支从develop分支拉取，用于回归测试，完成后打tag并合入master和develop。
hotfix
hotfix分支用于紧急修复上线版本的问题，修复后打tag并合入master和develop。
新功能的开发
所有版本新功能的开发都在feature上开发，这样确保了dev分支在开发的时候保留关键节点
在开发过程中在自己的分支开发可以随意操作分支，不会对其他人的代码产生破坏
版本的发布与回退
master上是干净的，所有的提交都是一个版本记录,当需要版本回退时，只需要检出某个历史版本，即可快速回退
过时分支的处理
除了 master 与 develop 是永久性分支以外，其他分支在使用完以后都需要及时清理，保持分支的简洁
合并分支
压缩提交
当Feature分支往Develop分支上合并或者Develop分支往Master分支上合并时，需要对Feature分支上的提交进行压缩，保留几个有效的提交，提交无用提交
常用的压缩命令是 git rebase
Hotfix修复
Hotfix分支主要用于修复master上的分支，并合并一份到Develop上，保证Develop后续分支不会出错
但是如果Realase分支已经存在了，那么就无法获取到Develop上的更改，这时候Hotfix也需要往Release分支上合并一次
记住不是Develop往Release上合并，这样如果处理不当，会无意导致Develop上在Release之后的更改合并到Release上，导致问题出现
新项目
当我们有多个项目，他们的功能稍微不同，但是却基于同一个项目，该如何处理？
如果两个项目以后要合并为一个项目，那么推荐在原有主分支上重新拉一个保护分支，用作新项目的主分支
否则重新创建一个仓库，将代码迁移一份到新项目中继续开发
Git Flow 真的完美吗？
合并问题
所有人在自己的代码开发会导致代码异化增加，冗长的代码提交会增加合并冲突的几率以及冲突代码量增加
不可在 feature 过长时间进行开发，否则feature上的代码很可能过时，develop上的代码更新不会反馈到feature分支上
临时性分支的代码最终走向还是 develop ，feature 只是在某个程度上缓解了 develop被污染的可能
减少代码异化
feature分支在开发时，应每隔一段时间往dev上合并一次代码，同时从dev上合并一次代码到feature上
如果项目需要调整目录结构、大幅改动时，应通知所有feature上开发的人员合并代码到dev上，再重新拉取新feature，否则容易导致代码大量冲突
持续集成
Git Flow 反馈时间长，集成周期相对较长，不符合持续集成的思想
相较与其他工作流模型，Git Flow 的持续集成能力较弱
繁杂的分支
在开发过程中，会生产很多分支，如果命名不当，将导致分支混乱，没有丰富的git使用经验的人员很可能搞错，所以在使用时在命名和分支层次上需要特别注意
多个团队同时开发一个项目，容易导致分支失控
惨遭吐槽
Gitflow不是Git社区的官方推荐工作流，也不是Github所推荐的工作流，Gitflow在企业软件开发中甚至不是一个最佳实践
那为什么还有那么多人使用它？
因为没有比它更适合企业开发的工作流模型了
Forking 工作流
Forking工作流常用于开源项目，它有一个公开的中央仓库，其他贡献者可以Fork（克隆）这个仓库作为你自己的私有仓库，开源项目维护者可以直接往中央仓库push代码，而代码贡献者只能将代码push到自己的私有仓库，只有项目维护者接受代码贡献者往中央仓库发起的pull request才会真正合入。
图解
Trunk based Development
Trunk based Development，又叫 主干开发 ，是一套代码分支管理策略，开发人员之间通过约定向被指定为 主干 的分支提交代码，以此抵抗因为长期存在的多分支导致的开发压力。此举可 避免分支合并的困扰，保证随时拥有可发布的版本 。
Trunk Based Development
Git Hub flow
GitHub Flow 是一个更轻量级的软件开发模型，示意图如下。它摒弃了 Git Flow 中繁杂的分支， 只保留一个主分支 master 。开发新功能时从 master 分支上拉取 feature 分支，开发完成后发起 Pull-Request ，小组内进行评审和反馈，此时也进行 Code Review
图解
