（图片来自https://www.cnblogs.com/cnblogsfans/p/5075073.html）
总的来说Git就是使用它快速创建和切换分支的特性，在开发过程中通过分支来完成功能的开发、Bug修复以及代码发布。
更多信息可参考：
https://blog.csdn.net/wwj_748/article/details/55226044
前面介绍了Git的特性之一“分支”的工作流，那么Git的特性之二“分布式”又会对开发模式带来什么样的变化？
再谈集中式工作流 为什么又是集中式工作流？文章前面介绍的集中式工作流主要偏重于“分支”，所有工作的内容提交到一个Trunk或者Master的分支上。
而这里的集中式工作流是针对与代码仓库来说的，所有开发人员使用同一个代码仓库进行协同工作，Git中使用集中式工作流时还可以采用特性分支或者Git Flow工作流来体现Git分支带来的便利(注：如果一个项目的贡献者只有一个人的话，实际上集中式工作流联合特性或Git flow来进行开发是最适合的)：
在使用集中式版本控制工具时，使用的就是集中式工作流，所有的开发人员共享一个代码仓库，当其中一人提交代码时需要先更新其它人的提交，可能会出现代码冲突需要合并，还有可能会将其它人的提交覆盖掉，同时由于无法保证代码质量，甚至会出现引入了其它开发人员的代码导致编译不通过、测试不通过等等问题，所以在使用集中式工作流程的时候最不能缺少的就是“沟通”。
对于开源项目来说开发人员来自全世界，其沟通成本远远大于本地团队，那么作为开源项目使用最广泛的版本控制工具，它是如何解决协同开发问题？
Git中可以创建多个仓库，集成管理者工作流的核心就是项目的主仓库由“集成者”负责，其它开发人员拥有自己的仓库，开发者把完成的工作提交到自己的公开库中，然后“集成者”从这些公开库中拉取代码，最终合并到主仓库中，如下图：
这样做有以下几个好处：
开发人员有自己的代码库，减少了更新、合并等操作(注：更新、合并的根源在于不同开发任务之间的依赖，如果依赖严重，那么更新、合并是不可避免的，最理想的情况是没有依赖，那么开发人员只需完成自己的工作提交即可)。
所有代码合并由“集成者”完成合并，而一般“集成者”由经验丰富的程序员担任，代码合并的过程强制进行了代码复审，对于代码的质量是可控的，有效保证主项目代码的干净整洁。
由于代码的复审，开发人员在提交代码时也不会太随意，变相提高了代码质量。
但是相对于集中式的工作流来说由于需要等待合并，提交工作也比较复杂，所以开发效率会相对降低。
司令官与副官工作流司令官与副官工作流是集成管理者工作流的拓展，引入了多级“集成者”来完成多级的代码合并操作，该模式适用于复杂的多级管理的项目开发：
更多关于Git分布式工作流的内容可参考：https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows
Pull Request 在Git中无论是集中式工作流还是集成管理者工作流，它都有一个核心的操作就是合并代码，对于集中式工作流来说，当分支完成开发后，需要将代码进行合并，一般是将分支代码合并到远程的如Master或Develop之类的长期分支上，其流程如下：
1. 创建一个功能分支feature1(git checkout -b feature1)。
2. 在分支上完成功能并提交(git add & git commit)。
3. 切换到master分支执行合并操作，并将更新推到远程仓库(git checkout master, git merge feature1, git push)。
4. 删除特性分支(git branch -d feature1)。
过程如下图所示：