Paste_Image.png

]](http://blog.jobbole.com/76861/)

Forking工作流和前面讨论的几种工作流有根本的不同。这种工作流不是使用单个服务端仓库作为『中央』代码基线，而让各个开发者都有一个服务端仓库。这意味着各个代码贡献者有2个Git
仓库而不是1个：一个本地私有的，另一个服务端公开的。

效果就是一个分布式的工作流，能为大型、自发性的团队（包括了不受信的第三方）提供灵活的方式来安全的协作。也让这个工作流成为开源项目的理想工作流。

工作方式

1. 一个新的开发者想要参与开发这个项目时，要fork正式项目在服务器上创建一个拷贝。这个仓库拷贝作为他个人公开仓库 —— 其它开发者不允许push到这个仓库，但可以pull到修改。在创建了自己服务端拷贝之后，和之前的工作流一样，开发者执行git clone命令克隆仓库到本地机器上，作为私有的开发环境。
2. 要提交本地修改时，push提交到自己公开仓库中 —— 而不是正式仓库中。然后，给正式仓库发起一个pull request。
3. 维护者pull贡献者的变更到自己的本地仓库中，检查变更以确保不会让项目出错，合并变更到自己本地的master分支，然后pushmaster分支到服务器的正式仓库中。到此，贡献的提交成为了项目的一部分，其它的开发者应该执行pull操作与正式仓库同步自己本地仓库。

*其他方面内容与功能分支工作流和Gitflow工作流一样。

、
Pull Request工作流

Pull Requests是Bitbucket上方便开发者之间协作的功能。提供了一个用户友好的Web界面，在集成提交的变更到正式项目前可以对变更进行讨论。

功能

1. 通知功能开发已经完成
2. 完成Code Review和合并到master分支
3. 为讨论提交的功能提供一个专门论坛
4. 有助于打造一个更流畅的工作流

工作方式

基本过程：

1. 开发者在本地仓库中新建一个专门的分支开发功能。
2. 开发者push分支修改到公开的Bitbucket仓库中。
3. 开发者通过Bitbucket发起一个Pull Request。
4. 团队的其它成员review code，讨论并修改。
5. 项目维护者合并功能到官方仓库中并关闭Pull Request。

在功能分支工作流中使用Pull Request

功能分支工作流只有一个公开的仓库，所以Pull Request的目的仓库和源仓库总是同一个。通常开发者会指定他的功能分支作为源分支，master分支作为目的分支。
收到Pull Request后，项目维护者要决定如何做。如果功能没问题，就简单地合并到master分支，关闭Pull Request。但如果提交的变更有问题，他可以在Pull Request中反馈。之后新加的提交也会评论之后接着显示出来。
在功能还没有完全开发完的时候，也可能发起一个Pull Request。比如开发者在实现某个需求时碰到了麻烦，他可以发一个包含正在进行中工作的Pull Request。其它的开发者可以在Pull Request提供建议，或者甚至直接添加提交来解决问题.

在Gitflow工作流中使用Pull Request

新功能一般合并到develop分支，而发布和热修复则要同时合并到develop分支和master分支上。Pull Request
可能用做所有合并的正式管理。

在Forking工作流中使用Pull Request

由于各个开发有自己的公开仓库，Pull Request的源仓库和目标仓库不是同一个。源仓库是开发者的公开仓库，源分支是包含了修改的分支。如果开发者要合并修改到正式代码库中，那么目标仓库是正式仓库，目标分支master分支。

Pull Request也可以用于正式项目之外的其它开发者之间的协作。比如，如果一个开发者和一个团队成员一起开发一个功能，他们可以发起一个Pull Request，用团队成员的Bitbucket仓库作为目标，而不是正式项目的仓库。然后使用相同的功能分支作为源和目标分支。

2个开发者之间可以在Pull Request中讨论和开发功能。完成开发后，他们可以发起另一个Pull Request，请求合并功能到正式的master分支。在Forking工作流中，这样的灵活性让Pull Request成为一个强有力的协作工具。