Git工作流可以理解为团队成员遵守的一种代码管理方案，在Git中有以下几种常见工作流：
- 集中式工作流
- 功能开发工作流
- Gitflow工作流
- Forking工作流
1）集中式工作流
这种工作方式跟svn类似，它只有一个master分支，开发者会先把远程的仓库克隆到本地，之后的修改和提交都在本地操作，直到在某个合适的时间点将本地的代码合入到远程master。这种工作流比较适合小团队，因为小团队可能不会太多的协作和合流的动作。
2）功能开发工作流
这种工作流关注功能开发，不直接往master提交代码保证它是稳定并且干净的，而是从master拉取feature分支进行功能开发，团队成员根据分工拉取不同的功能分支来进行不同的功能开发，这样就可以完全隔离开每个人的工作。当功能开发完成后，会向master分支发起Pull Request，只有审核通过的代码才真正允许合入master，这样就加强了团队成员之间的代码交流，也就是我们常说的Code Review。
3）Gitflow工作流
该种工作流会相对复杂一点，但非常适合用来管理大型项目的发布和维护。贯穿整个开发周期，master和develop分支是一直存在的。
master分支可以被视为稳定的分支，一般不允许直接往master分支提交代码，只允许往这个分支发起merge request，只允许release分支和hotfix分支进行合流。
develop分支是相对稳定的分支，用于日常开发，包括代码优化、功能性开发。
feature分支从develop分支拉取，特性开发会在其上进行，开发完毕合后并到develop分支。
release分支从develop分支拉取，用于回归测试，完成后打tag并合入master和develop。
hotfix分支用于紧急修复上线版本的问题，修复后打tag并合入master和develop。
4）Forking工作流
Forking工作流常用于开源项目，它有一个公开的中央仓库，其他贡献者可以Fork（克隆）这个仓库作为你自己的私有仓库，开源项目维护者可以直接往中央仓库push代码，而代码贡献者只能将代码push到自己的私有仓库，只有项目维护者接受代码贡献者往中央仓库发起的pull request才会真正合入。
Reference:
https://blog.csdn.net/wwj_748/article/details/55226044