1、分布式工作流程
与传统的集中式版本控制系统（CVCS）相反，Git 的分布式特性，使开发者间的协作变得更加灵活多样。
在集中式版本控制系统中，每个开发者就像是连接在集线器上的节点，彼此的工作方式大体相像。 而在 Git 中，每个开发者同时扮演着节点和集线器的角色。也就是说， 每个开发者既可以将自己的代码贡献到其他的仓库中，同时也能维护自己的公开仓库， 让其他人可以在其基础上工作并贡献代码。
由此，Git 的分布式协作可以为你的项目和团队，衍生出种种不同的工作流程， 接下来会介绍几种常见Git工作流程。
你可以选择使用其中的某一种，或者将它们的特性混合搭配使用。
2、集中式工作流
Git为了便于客户机之间的协同工作，Git版本控制系统一般会设置一个中央版本库服务器，目的是让所有客户机都从该主机更新版本，提交最新版本，该工作模式下的客户机地位都平等。
集中式工作流像SVN一样，以中央仓库作为项目所有修改的单点实体，所有修改都提交到 Master分支上。这种方式与 SVN 的主要区别就是开发人员有本地库，但是Git 很多特性并没有用到。
如下图：
上图说明：
- 一个远程仓库，
- 一个主分支master，
- 团队每个成员都有一个本地仓库，在本地仓库中进行代码的编辑、暂存和提交工作。
集中式工作流总结：
适用人群：小型开发小团队，习惯使用SVN工具的小团队。
-
工作方式：
- 团队组长创建远程仓库，创建一个master分支，组员可读可写。
- 每个开发人员都
git clone远程仓库到本地仓库，在master分支上开发。 - 每次开发都要
git pull更新远程仓库的master分支版本到本地。 - 每次开发完成就
git commit到本地仓库， 接着git push到远程仓库。
-
缺点：
- 忘了
git push，一直会提交到本地仓库，没有推送到远程仓库。 - 忘了
git pull，导致本地仓库与中央仓库不一致，发生文件冲突。 - 大量操作
git pull，导致增加Git分支合并次数，增加了Git变基次数，降低了Git的性能。
- 忘了
3、分支工作流
功能分支工作流在集中式工作流的基础上，为各个新功能分配一个专门的分支来开发，即在master主分支外在创建一个分支，程序员开发的新功能全部push到此分支上，等到功能成熟的时候，再把此分支合并到主分支master上。
如下图：
分支工作流总结：
适用人群：小型开发团队，熟悉Git分支的团队。
-
工作方式：
- 团队组长创建远程仓库，创建一个master分支，组员可读不可写。
- 每个开发人员都
git clone远程仓库到本地仓库。 - 每个开发人员创建自己的feature分支，在feature分支上开发。（记住，feature分支是基于master分支）
- 每个开发人员每次开发完成就
git commit到本地仓库中自己的feature分支， 接着git push到远程仓库。 - 通过
pull request提醒团队组长，浏览组员提交feature分支。 - 组长把feature分支拉下来，然后合并到自己本地仓库的master分支上测试。
- 组长测试feature分支通过之后，由组长负责把feature分支合并到远程仓库的master分支上。
- 组长在远程仓库把合并过的feature分支删除。
- 组员在本地仓库把合并过的feature分支删除。
- 组员将本地仓库分支切换为master分支，然后
git pull将本地仓库的master分支更新到远程仓库的master分支版本。
-
缺点：
- 增加团队组长的工作量。
- 增加团队组员提交步骤。
PS：
Pull Request作用是可以让其他组员或组长可以查看你的代码，并可以提出代码修改意见或者讨论。
参考：
