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

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

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

如果你已经对公司或团队中的集中式工作流感到满意，则可以轻松地继续将该工作流与 Git 一起使用。 只需设置一个仓库，并授予团队中的每个人推送访问权限； Git 不会让用户覆盖彼此的内容。

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

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

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

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

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

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

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