Git工作流面面观——Forking工作流

注： 本文采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。

Forking工作流

Forking工作流(Forking Workflow)和其他工作流不同的地方在于，它是一种真正意义上的分布式工作流。

个人库 vs. 官方库

这种工作流允许每个开发人员都拥有属于自己的远程Git库，而不是所有人集中共享一个远程库。每一个采用Forking工作流的项目都有一个唯一的官方远程库，其他人则从这个官方远程库fork出自己的个人远程库。

对于这两种远程库，我们在本地使用Git时，通常会为它们起相应的名字，比如：个人远程库习惯叫做origin，官方远程库习惯叫做upstream。

Fork vs. Clone

Git里并没有提供专门的fork命令，fork作为一项功能，通常是由第三方的Git服务来提供的，比如像：Github，Bitbucket，Gitlab。实际上，fork就是标准的git clone，它把Git库保存的全部内容以及提交历史完整地复制了一遍。

和普通的clone有所不同的是，fork是发生在服务器上的Git库之间的复制。而普通的clone，则是把服务器上的Git库复制到本地。

参与者 vs. 维护者

作为Forking工作流里出现的两类重要的角色，项目的参与者(Contributors)和维护者(Maintainers)，官方库面向所有的参与者开放只读权限，而只有维护者才对它具有写的权限。

这样做的好处在于，项目维护者不再需要单独为每一个想加入该项目的参与者手工进行授权了。因为大家都有只读权限，所以任何人只要把官方库fork成他自己的个人库，马上就可以开始工作。每个人对他自己的个人库是具有完全的读写权限的。

直接推送 vs. 间接推送

项目参与者在自己的个人库里工作的时候，同样遵循Git的分支模型，也可以使用其他工作流，比如：特性分支工作流，Gitflow工作流等。但是和其他Git工作流不同的是，他们会把本地的提交先推送到自己的个人远程库，而不是直接推送到官方远程库。然后再通过发起Pull Request的方式，尝试把个人库里的内容合并到官方库。在这个过程中，可以和包括项目维护者在内的其他人针对要合并的内容进行审查和讨论。

灵活性

这种方式，一方面赋予了项目参与者极大的自主权，他们不用等待项目维护者的代码评审结论，而是可以并行地在自己的个人库里继续他们的开发工作。如果fork出来的个人库不再需要了，甚至还可以直接把它删除掉。

另一方面，这也为项目维护者提供了充分的自由度，他们可以选择在任何时候决定是否接受来自其他参与者的提交，要不要推送到官方的远程库。

这样一来，包括参与者和维护者在内，所有人都可以在自己的独立空间里按照自己的节奏来工作。从而体现了极大的灵活性，非常适合大规模团队，或者是组织松散的异地团队进行协作开发，所以最常在开源项目里见到。

约束性

不仅如此，由于代码最终能够进入官方库的唯一渠道就是得到项目维护者的主动认可和推送，因为只有他们才具有对官方库的写权限。所以，尽管这种工作方式表面上看起来很松散，但实际上它依然具有很好的约束性，能够有效地保证项目的代码质量。

如何工作

相信大家在掌握了其他几种Git工作流以后，再来理解Forking工作流的工作方式，应该是非常容易的。下面列出大致的流程：

• 第一步，作为项目参与者的开发人员在开始工作之前，先从官方的远程库fork一份拷贝作为自己的私人远程库，然后再把私人远程库clone到本地，作为本地的私人开发环境；
• 第二步，开发人员在本地可以继续使用其他Git工作流进行项目开发，比如：创建新的特性分支，并在分支上进行新特性的开发；
• 第三步，开发人员把本地的提交推送到自己的个人远程库，作为工作备份，也作为和其他人协同工作的基础；
• 第四步，如果已经准备好推送给官方的远程库，那就发起Pull Request，通知项目维护者进行代码复查；
• 第五步，项目维护者把Pull Request涉及的变更抓取到本地，进行测试和验证。如果有问题，那就告之项目参与者继续修改。如果没有问题，也就是Pull Request审批通过了，那就合并到官方库的本地主分支，然后再推送到远程；
• 第六步，所有人可以通过从官方远程库抓取变更的方式，把其他人刚刚合并的最新工作同步到本地；