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

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

这意味着，如果两个开发人员从枢纽克隆并都进行了更改，第一个将更改推回的人可以毫无问题地完成。第二个开发人员在推送更改之前必须合并第一个开发人员的工作，以免覆盖第一个开发人员的更改。这个概念在 Git 中与在 Subversion（或任何 CVCS）中一样真实，而且这种模式在 Git 中也能完美运行。

如果您已经习惯了公司或团队中的集中式工作流，那么您可以使用 Git 轻松地继续使用该工作流。只需设置一个仓库，并给予团队中的每个人推送权限；Git 不会让用户覆盖彼此。

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

这也不仅限于小型团队。借助 Git 的分支模型，数百名开发人员可以同时在数十个分支上成功地处理单个项目。

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

这是像 GitHub 或 GitLab 这样的基于 Hub 的工具中非常常见的工作流，在那里可以轻松地 Fork 一个项目并将您的更改推送到您的 Fork 中供大家查看。这种方法的主要优点之一是您可以继续工作，而主仓库的维护者可以随时拉取您的更改。贡献者不必等待项目合并他们的更改——双方都可以按照自己的节奏工作。

这是多仓库工作流的一个变体。它通常由拥有数百名协作者的庞大项目使用；一个著名的例子是 Linux 内核。各种集成经理负责仓库的特定部分；他们被称为副手。所有副手都有一个被称为仁慈的独裁者的集成经理。仁慈的独裁者从其目录推送到一个参考仓库，所有协作者都需要从中拉取。该过程如下（请参阅 仁慈的独裁者工作流）

这种工作流并不常见，但在非常大的项目或高度分层的环境中可能很有用。它允许项目负责人（独裁者）委派大量工作，并在多个点收集大块代码，然后再将其集成。

这些是像 Git 这样的分布式系统可能支持的一些常用工作流，但您可以看到，可能存在许多变体来适应您特定的实际工作流。现在您（希望）可以确定哪种工作流组合可能适合您，我们将介绍一些更具体的示例，说明如何完成构成不同流程的主要角色。在下一节中，您将学习一些贡献项目的常见模式。