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

在集中式系统中，通常只有一种协作模型——集中式工作流程。一个中心枢纽或仓库负责接收代码，每个人都与它同步工作。许多开发者作为节点——即该中心的使用者——与这个集中的位置进行同步。

这意味着，如果两个开发者从中心仓库克隆代码并都进行了更改，第一个推送更改的开发者可以顺利完成操作。第二个开发者必须先合并第一个人的工作，然后才能推送自己的更改，以免覆盖前者的工作。这个概念在 Git 中与在 Subversion（或任何 CVCS）中一样适用，这种模型在 Git 中也能完美运行。

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

假设 John 和 Jessica 同时开始工作。John 完成了他的更改并将其推送到服务器。然后 Jessica 尝试推送她的更改，但服务器拒绝了。她被告知正在尝试推送非快进（non-fast-forward）的更改，在执行抓取（fetch）并合并（merge）之前，她无法进行推送。这种工作流程对许多人来说很有吸引力，因为它是一个许多人都熟悉且感到舒适的范式。

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

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

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

这是多仓库工作流程的一种变体。它通常被拥有数百名协作者的大型项目所使用；一个著名的例子是 Linux 内核。各种整合者负责仓库的特定部分；他们被称为副官（lieutenants）。所有的副官都由一名整合者管理，被称为仁慈的独裁者（benevolent dictator）。仁慈的独裁者将更改从他们的目录推送到参考仓库，所有协作者都需要从中进行拉取。该过程如下所示（参见 仁慈的独裁者工作流程）：

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

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