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

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

这意味着如果两个开发者从中心克隆并都做出更改，第一个将更改推送回去的开发者可以顺利完成。第二个开发者必须在推送更改之前合并第一个开发者的工作，以免覆盖第一个开发者的更改。这个概念在 Git 中与在 Subversion（或任何 CVCS）中一样真实，并且这种模型在 Git 中也运作良好。

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

假设 John 和 Jessica 同时开始工作。John 完成他的更改并将其推送到服务器。然后 Jessica 尝试推送她的更改，但服务器拒绝了。她被告知她正在尝试推送非快进更改，并且她将无法这样做，直到她先抓取并合并。这种工作流对很多人来说很有吸引力，因为它是一个许多人都熟悉和适应的范例。

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

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

这是一种在 GitHub 或 GitLab 等基于 Hub 的工具中非常常见的工作流，在这些工具中，很容易分叉一个项目并将你的更改推送到你的分叉中供所有人查看。这种方法的主要优点之一是你可以继续工作，而主仓库的维护者可以随时拉取你的更改。贡献者不必等待项目整合他们的更改——各方都可以按照自己的节奏工作。

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

这种工作流并不常见，但对于非常大的项目或高度层级化的环境可能很有用。它允许项目负责人（独裁者）委派大部分工作，并在整合之前在多个点收集大量的代码子集。

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