派生（forking）工作流与其他流行的 Git 工作流根本不同。它没有使用单个服务器端仓库作为“中央”代码库，而是为每个开发人员提供了自己的服务器端仓库。这意味着每个贡献者都是两个 Git 仓库：一个私有本地仓库和一个公共服务器端仓库。派生工作流最常见于公共开源项目中。
派生工作流的主要优点是可以集成贡献，而无需每个人都将其推送到单个中央仓库。开发人员将推送到他们自己的服务器端仓库，只有项目维护者才能推送到官方仓库。这使维护者可以接受任何开发人员的提交，而无需授予他们对官方代码库的写访问权限。
派生工作流通常遵循基于《Git工作流之GitFlow工作流》的分支模型。这意味着将使用完整的功能分支来合并到原始项目维护者的仓库中。结果是一个分布式工作流，为大型组织团队（包括不受信任的第三方）提供灵活的方式来安全地进行协作。这也使其成为开源项目的理想工作流程。
运作原理
与其他 Git 工作流程一样，派生工作流从存储在服务器上的官方公共仓库开始。但是，当新的开发人员希望开始从事该项目时，他们不会直接克隆官方仓库。
相反，他们派生（fork）了官方仓库以在服务器上创建它的副本。此新副本将用作其个人公共存储库-不允许其他开发人员将其推送到其中，但他们可以从中进行更改（我们稍后将解释为什么这很重要）。在创建服务器端副本之后，开发人员执行，git clone将其副本复制到本地计算机上。就像其他工作流程一样，这是他们的私有开发环境。
准备发布本地提交时，他们会将提交推送到自己的公共仓库中，而不是正式的仓库中。然后，他们向主仓库提交合并请求（pull request），这使项目维护者知道已准备好要集成更新。如果所贡献的代码存在问题，则合并请求还可以用作方便的讨论线程。以下是此工作流程的分步示例。
- 开发人员
派生（fork）一个“官方”服务器端存储库（这将创建自己的服务器端副本）； - 新的服务器端副本将克隆（
git clone）到其本地； - “官方”存储库的 Git 远程路径添加到本地（
git remote add origin xxx）； - 创建一个新的本地
功能分支（feature branch）； - 开发人员在新功能分支上进行更改；
- 将为更改创建新的提交（
git add && git commit）； - 分支被推送到开发人员自己的服务器端（副本）；
- 开发人员打开从新分支到“官方”存储库的
合并请求（pull request）； - 合并请求被批准用于合并，并被合并到原始服务器端存储库中。
为了将完成的功能集成到官方代码库中，维护人员将贡献者的更改拉入他们的本地存储库，检查以确保它不会破坏项目，将其合并到其本地 master 分支中，然后将其推送到服务器上的官方存储库中。贡献现在是项目的一部分，其他开发人员应从官方存储库中提取信息以同步其本地存储库。
重要的是要了解，Forking 工作流中“正式”存储库的概念仅仅是一个约定。实际上，使正式存储库如此正式的唯一原因是它是项目维护者的公共存储库。
派生与克隆（Forking vs cloning）
需要注意：“派生”不是特殊操作。派生的存储库是使用标准的git clone命令创建的。派生的存储库通常是“服务器端克隆”，通常由诸如Bitbucket、Gitlab 之类的第三方 Git 服务进行管理和托管。
在派生工作流中分支
就像功能分支工作流（Feature Branch Workflow）和 Gitflow 工作流一样，开发者仍然应该使用分支来隔离各个功能。唯一的区别是这些分支如何共享。在派生（Forking）工作流中，中央存储库被拉到另一个开发人员的本地存储库中，而在功能分支工作流和 Gitflow 工作流中，它们被推到官方存储库中。
派生存储库（Fork a repository）
派生（Forking）工作流项目的所有新开发人员都需要派生正式存储库。如前所述，派生只是一种标准git clone操作。可以通过 SSH进入服务器并运行git clone将其复制到服务器上的另一个位置来实现。流行的 Git 托管服务提供了自动执行此步骤的派生功能。
克隆派生仓库（Clone your fork）
1 | git clone https://user@bitbucket.org/user/repo.git |
添加远程跟踪分支（Adding a remote）
其他 Git 工作流程使用指向中央存储库的单个原始远程服务器，而 Forking 工作流则需要两个远程服务器-一个用于官方存储库，一个用于开发人员的个人服务器端存储库。虽然您可以随意调用这些远程服务器，但通常的约定是使用origin作为派生存储库的远程服务器（运行git clone时将自动创建该远程服务器），并使用上游作为正式存储库的远程服务器。
1 | git remote add upstream https://bitbucket.org/maintainer/repo |
在分支中工作：开发和推送更改（making & pushing changes）
就像其他 Git 工作流程中一样，他们可以在开发人员的本地化分支存储库副本中编辑代码，提交更改并创建分支：
1 | git checkout -b some-feature # Edit some code |
他们所做的所有更改都将完全是私有的，直到将其推送到其公共存储库中为止。而且，如果正式项目向前发展，他们可以使用git pull访问新的提交：
1 | git pull upstream master |
由于开发人员应在专用功能分支中工作，因此通常应导致快速合并。
发起合并请求（Making a Pull Request）
一旦开发人员准备好共享他们的新功能，他们需要做两件事。首先，他们必须将其贡献推送到其公共存储库中，以使其他开发人员可以访问他们的贡献。他们的源远程跟踪库应该已经设置好了，所以他们要做的就是以下操作：
1 | git push origin feature-branch |
其次，他们需要通知项目维护者他们想将其功能合并到官方代码库中。Git 托管服务（如 Bitbucket、Gitlab）提供了一个“合并请求（pull request）”按钮，该按钮会提交一个表单，要求您指定要合并到官方存储库中的分支。通常，您需要将功能分支集成到上游远程的主分支中。
总结
回顾一下，派生（Forking）工作流通常在公共开源项目中使用。派生是在项目存储库的服务器副本上执行的git clone操作。派生工作流通常与 Bitbucket 之类的 Git 托管服务结合使用。
派生（forking）工作流的高级示例是：
- 您想为托管在
bitbucket.org/userA/open-project上的开源库做出贡献； - 使用 Bitbucket，您可以创建一个仓库的分支到
bitbucket.org/YourName/open-project； - 在您的本地，您可以运行
git clone以获取仓库的本地副本； - 您在本地仓库中创建一个新的
功能分支； - 完成新功能的工作已完成，并运行
git commit执行了保存更改的工作； - 然后，您将新
功能分支推送到您的远程派生仓库中； - 使用 Bitbucket 您可以在
bitbucket.org/userA/open-project上针对原始仓库对新分支发起一个合并请求（pull request）。
派生（forking）工作流可帮助项目的维护者打开存储库以接受任何开发人员的贡献，而不必手动管理每个贡献者的授权设置。这为维护人员提供了更多的“拉”式工作流程。派生（forking）工作流最常用于开放源代码项目，也可以应用于私有业务工作流，以从对合并到发行进行更权威的控制，这对于具有发布部署管理或严格发布周期的团队很有用。
不确定哪种工作流程适合您？查看我们全面的Git 工作流比较页面。
