Git工作流
Fork工作流
每个开发者两个仓库， 一个公开的服务器的仓库和一个私有本地的仓库。
Fork工作流的主要优点在于贡献可以轻易地整合进项目，而不需要每个人都推送到单一的中央仓库。开发者推送到他们 自己的 服务端仓库，只有项目管理者可以推送到官方仓库。这使得管理者可以接受任何开发者的提交，却不需要给他们中央仓库的权限。
-
Fork工作流以一个储存在服务端的官方公开项目开场。他们fork一份官方项目，在服务端创建一份副本。这份新建的副本作为他们私有的公开仓库——没有其他开发者可以在上面推送，但他们可以从上面拉取修改（在后面我们会讨论为什么这一点很重要）。在他们创建了服务端副本之后，开发者执行git clone操作，在他们的本地机器上复制一份。这是他们私有的开发环境，正如其他工作流中一样。
-
当他们准备好发布本地提交时，他们将提交推送到自己的公开仓库——而非官方仓库。然后，他们向主仓库发起一个pull request，让项目维护者知道一个更新做好了合并的准备。如果贡献的代码有什么问题的话，Pull request可以作为一个方便的讨论版。
-
维护者将贡献者的修改拉取到他们的本地仓库，确保修改不会破坏项目，将它合并到本地的master分支，然后将master分支推送到服务端的官方仓库。贡献现在已是项目的一部分，其他开发者应该从官方仓库拉取并同步他们的本地仓库。
中央仓库
“官方”仓库这个概念在Fork工作流中只是一个约定，理解这一点很重要。从技术的角度，Git并看不出每个开发者和官方的公开仓库有什么区别。事实上，官方仓库唯一官方的原因是，它是项目维护者的仓库。
Fork工作流中的分支
所有这些个人的公开仓库只是一个在开发者之间共享分支的约定。每个人仍然可以使用分支来隔离功能，就像在功能分支工作流和Gitflow工作流中一样。唯一的区别在于这些分支是如何开始的。在Fork工作流中，它们从另一个开发者的本地仓库拉取而来，而在功能分支和Gitflow分支它们被推送到官方仓库。