Git - 分布式工作流

---

---

分布式工作流

Git 的分布式架构允许比集中式版本控制系统 (CVCS) 更灵活的协作。

• Git 中的每个开发人员都既是潜在的中心节点，也是节点本身。

• 通过各种可用的工作流选项，开发人员可以维护自己的公共存储库并为其他人的存储库做出贡献。

• 我们将深入了解一些流行的分布式工作流概念。

• 它提请注意它们的优点、缺点以及结合来自多个角度的元素的能力。

分布式工作流的优势

分布式工作流有很多优势，例如

• 协作 - 主要优势之一是，当多个贡献者或开发人员可以一起在一个存储库上工作时，不会影响彼此的工作。

• 灵活性 - 可以灵活地选择适合其团队结构和项目的工作流类型。

• 离线 - 对于远程和分布式团队，它使开发人员更容易离线工作，然后稍后同步他们的更改。

• 试用 - 使用分布式工作流，开发人员可以尝试和试验他们的想法，而无需更改主代码或基础代码。

工作流类型

集中式工作流

在集中式工作流系统中，中央存储库充当单个协作模型的中心焦点。

开发人员代码贡献的中心点是这个主存储库。

• 每个人都使用这个中央存储库来保持其工作的同步。

• 开发人员利用这个中央位置作为节点来使用和同步其更新。

• 如果两个开发人员从中央存储库克隆并都进行更改，则由于集中式工作流，第一个开发人员可以轻松地将其更改发送回。

• 但是，在推送他们所做的更改之前，第二个开发人员必须将其更改合并到自己的工作中。

• 通过这样做，他们可以确保不会覆盖第一个开发人员的工作。

Git 有效地支持此模型，并且此理念在 Subversion 和 Git 等版本控制系统中是一致的。

如果我们的团队习惯于集中式工作流，则切换到 Git 很简单。

创建一个单一的存储库，并为每个团队成员提供推送访问权限。

通过防止用户覆盖彼此的工作，Git 保留了可识别的集中式工作流结构。

• 开发人员 1 和开发人员 2 同时开始工作。完成工作后，开发人员 1 将更新推送到服务器。

• 开发人员 2 尝试推送她的更改，但服务器拒绝了它，因为更改与快速转发不兼容。

• 为了正确推送她自己的更改，开发人员 2 必须首先获取并合并最新的更改。

• 此工作流的便捷性和熟悉性使其广受欢迎。

• Git 的分支方法使其能够很好地扩展到小型团队之外。

• 使用 Git，数百名工程师可以一起在一个项目上工作，并轻松管理多个分支。

集成管理器工作流

Git 的适应性允许在协作工作流中使用多个远程存储库。

通常，每个开发人员都对其他开发人员的公共存储库具有读取访问权限，并对其自己的存储库具有写入访问权限。

• 项目的权威来源是规范存储库。

• 开发人员可以通过克隆项目、编辑他们自己的公共克隆并推送更新版本来做出贡献。

• 之后，主项目的维护者会收到开发人员的拉取请求。

• 维护者审查、测试并合并更改后，更改将被推回主存储库。

• 这种分散的过程允许协作开发，同时保持对项目的完整性控制。

流程如下

• 项目维护者将更新推送到公共存储库。

• 贡献者克隆维护者的存储库并添加更改。

• 贡献者将其更新版本上传到一个公共可访问的存储库。

• 通过电子邮件，贡献者请求维护者拉取更改。

• 维护者将贡献者的存储库添加为远程，并在本地合并更改。

• 然后，维护者将合并的更改推送到主存储库。

• 此过程简化了协作和对贡献的受监管集成。

这是 GitLab 或 GitHub 等平台的标准流程。

• 贡献者可以通过为项目创建分支来将更新发布到他们自己的公共分支存储库。

• 贡献者能够独立地在其分支上工作是一个主要优势。

• 主存储库维护者可以在方便的时候合并来自分支的更改。

  由于这种灵活性，贡献者不必等待项目的计划发生变化以反映他们的改进。

独裁者和副官工作流

多个存储库由副官监督，副官是集成管理员。

Linux 内核等项目是此过程的良好示例。

• 一个称为仁慈独裁者的中央权威受到副官的监督，副官负责项目的特定方面。

• 仁慈独裁者从其目录中收集更新并将其移动到参考文件。

• 之后，每个协作者都从这个参考存储库中拉取更新。

• 此方法确保在整个开发过程中进行集中控制和同步。

• 定期开发人员在其自己的主题分支上工作，他们经常将工作重新设置到参考存储库的主分支上。

• 将开发人员的主题分支合并到他们自己的主分支的任务属于副官。

• 独裁者将副官的主分支合并到一个主分支中。

• 最后，独裁者通过将其主分支推送到参考存储库来确保所有其他开发人员都可以重新设置其工作到此更新的主分支上。

虽然不常见，但此方法在分层环境或大型项目中具有优势。

它允许项目经理（独裁者）为副官分配重要任务。

副官在分支集成之前收集重要代码子集的不同时间点。

功能分支工作流

此工作流的核心思想是所有功能开发都应在专用分支中进行，而不是在主分支或 master 分支中进行。这会导致主分支在任何时候都拥有正确的代码，而不是错误的代码。

• 每个新的修复或功能都将在其自己的分支中开发，而不是主分支。

• 完成功能后，可以通过拉取请求将其合并到主分支中。

• 此方法使管理更改和审查代码变得更容易，因为新的修复或功能与主基础代码隔离。

Gitflow 工作流

Gitflow 工作流涉及功能分支和许多主分支。它具有许多生命周期较长的分支和较大的提交。它是一种更结构化的方法，并且包含各种分支类型

• 主用于生产就绪代码。

• 开发用于需要集成的功能。

• 功能分支用于要合并的新功能。

• 发布分支用于生产中的新版本。

• 修补程序分支用于代码中的紧急修复。

Gitflow 为开发和发布提供了非常清晰和组织良好的路径。

Forking 工作流

Forking 工作流为每个开发人员或贡献者提供他们自己的服务器端存储库，而不是使用单个服务器端存储库。

这意味着每个贡献者都有两个 Git 仓库，一个是私有的本地仓库，另一个是公开的服务器端仓库。

• 它通常用于公共开源项目。

• 贡献者分叉中央仓库以创建他们自己的副本。

• 开发者可以更改他们分叉的副本并向原始仓库提交拉取请求以供审查。

• 这是一种简单有效的方法，允许任何人进行贡献，而无需直接干扰主仓库的代码。

分叉仓库或分叉不是 Git 中任何特殊或不同的命令。分叉的仓库是使用标准的git clone命令创建的。这些仓库是服务器端克隆，通常由第三方 Git 服务提供商管理，例如 GitHub、BitBucket 等。

拉取请求工作流

拉取请求工作流是一种轻量级方法，它基于分支型工作流。

团队使用拉取请求来提出更改、讨论和审查代码更改，然后再合并。它通常与功能分支或分叉工作流结合使用，以实现有效的审查和代码协作。

以下是此工作流的步骤

• 1. 将更改拉取到您的本地仓库以获取最新的基础。现在创建一个分支。

• 2. 将更改提交到此新分支。

• 3. 将您的更改推送到新分支。

• 4. 打开一个拉取请求来提出更改。

• 5. 讨论和审查代码。

• 6. 对代码进行变基并测试它。

• 7. 最后，将您的分支合并到主分支。

主干开发工作流

在主干开发模型中，与 Gitflow 的长期分支相比，开发人员创建了具有少量小提交的短期分支。

• 开发人员直接在主分支或主干分支上工作。

• 更改会频繁集成。

• 最大限度地减少了长期分支和大型提交的使用。

• 这种方法强调更持续的集成。

每个工作流都有其自身的优势，应根据项目的需要和团队的偏好进行选择。因为所有不同的工作流都使团队能够利用 Git 强大的分支和合并功能进行协作。