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

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

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

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

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

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

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

这是使用像 GitHub 或 GitLab 这样基于枢纽的工具时非常常见的工作流，在这种工具中，你可以轻松地派生一个项目，并将你的更改推送到你的派生中供所有人查看。这种方法的主要优点之一是你可以继续工作，并且主仓库的维护者可以随时拉取你的更改。贡献者不必等待项目合并他们的更改——各方都可以按照自己的节奏工作。

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

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

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