5.1 分布式 Git - 分布式工作流

在集中式系统中，通常只有一种协作模式——集中式工作流。一个中央枢纽或仓库可以接受代码，并且每个人都与其同步他们的工作。许多开发人员是节点——中央枢纽的消费者——并与该集中式位置同步。

这意味着如果两个开发人员从枢纽克隆并且都进行了更改，那么第一个将更改推送到服务器的开发人员可以毫无问题地进行。第二个开发人员必须在将更改推送到服务器之前合并第一个开发人员的工作，以避免覆盖第一个开发人员的更改。这个概念在 Git 中与在 Subversion（或任何 CVCS） 中一样，并且此模型在 Git 中也能很好地工作。

如果你已经在公司或团队中习惯了集中式工作流，那么你就可以轻松地在 Git 中继续使用这种工作流。只需设置一个仓库，并授予团队中每个人推送访问权限；Git 不会让用户相互覆盖。

假设 John 和 Jessica 同时开始工作。John 完成了他的更改并将其推送到服务器。然后 Jessica 尝试推送她的更改，但服务器拒绝了。她被告知她正在尝试推送非快进更改，并且在获取和合并之前无法推送。这种工作流对很多人很有吸引力，因为它是一种许多人熟悉和舒适的模式。

这也不限于小型团队。通过 Git 的分支模型，数百名开发者可以成功地在同一个项目中通过数十个分支同时工作。

因为 Git 允许您拥有多个远程仓库，所以您可以使用一种工作流程，其中每个开发者对其自己的公共仓库拥有写入权限，并对其他人的仓库拥有读取权限。这种情况通常包括一个代表“官方”项目的规范仓库。要为该项目做出贡献，您需要创建项目的自己的公共克隆并将其更改推送到该克隆。然后，您可以向主项目的维护者发送请求，以拉取您的更改。维护者随后可以将您的仓库添加为远程仓库，在本地测试您的更改，将它们合并到其分支中，并将其推回其仓库。该流程如下所示（请参阅 集成管理器工作流程）。

这是一种非常常见的工作流程，使用像 GitHub 或 GitLab 这样的以中心仓库为基础的工具，在这些工具中，很容易对项目进行分叉并将您的更改推送到分叉中，以便所有人看到。这种方法的主要优点之一是，您可以继续工作，主仓库的维护者可以在任何时候拉取您的更改。贡献者不必等待项目整合他们的更改——每个参与者都可以按照自己的节奏工作。

这是多仓库工作流程的一种变体。它通常被拥有数百名协作者的大型项目使用；一个著名的例子是 Linux 内核。不同的集成管理器负责仓库的某些部分；他们被称为副官。所有副官都有一位集成管理器，被称为仁慈的独裁者。仁慈的独裁者将其目录中的更改推送到一个参考仓库，所有协作者都需要从该仓库拉取更改。该流程如下所示（请参阅 仁慈的独裁者工作流程）。

这种工作流程并不常见，但在非常大型的项目或高度分层环境中可能有用。它允许项目领导者（独裁者）将大部分工作委托出去，并在整合之前在多个点收集大量的代码子集。

这些是一些使用分布式系统（如 Git）可能使用的一些常用工作流程，但您可以看到，可以进行许多变体以适应您特定于现实世界的工作流程。现在您（希望）能够确定哪种工作流程组合可能适合您，我们将介绍一些关于如何完成构成不同流程的主要角色的更具体的示例。在下一节中，您将了解一些有关如何为项目做出贡献的常见模式。