从 Perforce 迁移到 Git 的分步指南

正如我们在上一篇文章中所讨论的那样,Git 现在几乎是所有类型数字开发的 SCM 事实上的选择。但是,如果您在 Perforce 中存储了多年的宝贵历史记录,那么您可能正在权衡转换的成本。在本文中,我们将直面如何解决这些问题,并告诉您如何将数据迁移到 Git。我们已将 Perforce 迁移到 Git 的流程分解为 8 个步骤:

第 1 步:移动 Perforce 数据

将数据从 Perforce 转移到 Git 有两种通用方法。在我们深入探讨该领域之前,我们需要考虑 Perforce 和 Git 处理软件项目的方式之间的根本区别。

Perforce 服务器可以容纳数十个或数百个不同的软件项目,每个项目都有自己的分支模型。开发人员定义了一个“视图”,告诉 Perforce 服务器将哪些文件放入工作副本中。另一方面,Git 存储库通常包含一个软件项目及其分支和标记(尽管确实存在大型单体 Git 代码存储库)。您通常会克隆代码存储库,并且还可以查阅子模块或子树。

因此,移动数据的问题分为两部分:如何从 Perforce 提取数据,以及如何将其转换为一组等效的 Git 存储库。

移动 Perforce 数据选项 1:使用 Git Fusion

如果您想在 Perforce 中保存数据的全部历史记录,您可以使用 Perforce 自己的 Git Fusion 工具将 Perforce 服务器(单个项目)的一部分提取到 Git 存储库中。本质上来说,您可以:

  • 安装 Git Fusion
  • 设置正确的数据视图,包括分支结构
  • 使用任何 Git 客户端从 Git Fusion 克隆
  • 将您的代码存储库推送到 Bitbucket
 实践示例 *为了完成这个示例,您需要一台已经运行 Git Fusion 的 Perforce 服务器。* 假设您有一个 Perforce 项目存在于存储库路径 //depot/acme/...(在 Perforce 存储库视图语法中)。它有三个分支: - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… 请记住,使用 Perforce 可以将分支视为树中的附加目录。 您的第一步是配置 Git Fusion,让它理解 Perforce 中的分支关系。为此,您需要创建一个代码存储库配置文件: [@repo] description = Acme project charset = utf8 [main] git-branch-name = main view = //depot/acme/main/… … [r1.0] git-branch-name = r1.0 view = //depot/acme/r1.0/…… [r1.1] git-branch-name = r1.1 view = //depot/acme/r1.1/…... 将此文件提交给 Perforce,路径为 //.git-fusion/repos/acme/p4gf_config 现在,使用普通的 Bitbucket 管理工具在 Bitbucket 中创建一个名为 acme 的空项目。您可以按照常用标准配置访问控制和团队成员。 接下来,从 Git Fusion 中克隆: git clone https:///acme cd acme git remote add bitbucket  git push –u --all bitbucket git push --tags Bitbucket 就是这样!现在,您应该可以在 Bitbucket 中看到导入的历史记录。

现在,这可能并不能始终为您提供 Perforce 数据的 100% 忠实副本。有些 Perforce 操作,比如部分合并,在 Git 中没有等效操作。但总而言之,这种方法可以让您轻松掌握大部分历史记录。

请记住,从传统 SCM 保留过去 10 年的分支历史记录并不意味着您必须继续使用相同的工作流程。值得注意的是,您应该考虑采用 Git Flow 等功能分支工作流程作为实际的第一步。

优点和缺点

  • 需要最多的设置工作和运行时间
  • 保留最多的历史记录(允许您关闭旧版 Perforce 服务器)
  • 保留历史记录中的传统分支模型

移动 Perforce 数据选项 2:重新开始

另一种选择是重新开始。忘掉那些笨重的历史记录:只需在 Perforce 中提取与您的项目相对应的每个分支的头部(尖端),然后将这些东西签出到新的空 Git 代码存储库中即可。(这意味着您已使用所需数据的正确“视图”定义了 Perforce 工作区。)

这是最简单和最快的技术。无论您的 Perforce 历史记录有多复杂,您的新 Git 代码存储库都是精简出色的。您有机会启动基于 Git 的新工作流程,而不会累积任何难题。

主要缺点是,您可能要让旧的 Perforce 服务器保持只读模式,以防有人出于任何原因需要深入研究历史代码。这不会花费您任何许可费,但它确实意味着您要让旧服务器存活一段时间。

 **实践示例** 进入您的 Perforce 工作区(签出项目数据主分支的目录)并运行: p4 sync 这将获取文件的最新版本。 现在,使用普通的 Bitbucket 管理工具在 Bitbucket 中创建一个名为 acme 的空项目。您可以按照常用标准配置访问控制和团队成员。 接下来,在您的工作区中创建一个新的 Git 代码存储库并推送到 Bitbucket: git init。 git remote add origin  git push –u --all origin git push --tags origin 现在,您应该会将代码的最新快照视为新 Bitbucket 项目中的首次提交。

优点和缺点

  • 快速简单
  • 重新设计分支模型和工作流程
  • 用于只读访问的传统 Perforce 服务器

第 2 步:用户和权限

移动数据后,下一个任务通常是开始将您的用户和权限映射到新的 Bitbucket 项目中。如果您使用 LDAP 作为用户目录,则可以在此处节省一些时间。或者,您可以使用 p4 users –o 命令轻松地从 Perforce 中提取一组用户帐户,将它们一次一个输入到 Bitbucket 中。

将 Perforce 权限转换为等效的 Bitbucket 权限可能很困难,因为 Perforce 权限既精细又复杂,有可能排除对单个文件的访问权限。这种复杂的权限架构是 Perforce 服务器陷入僵局的原因之一——每次访问尝试都可能导致服务器对复杂的数据结构执行昂贵的计算。

大多数情况下,要求项目负责人使用普通的项目、代码存储库和分支级别权限在 Bitbucket 中定义一组更简单的权限会更快。实际上,无论如何都需您要重新访问权限设置,因为 Git 提供了很多新的工作流程选项。例如,在 Perforce 中,您可能限制了分支创建,而在 Bitbucket 中,您可能只需要限制对主分支的推送访问权限。

第 3 步:二进制文件

如果您在 Perforce 中存储了大型二进制 blob,请仔细考虑如何在 Git 中进行管理。您可以试用 Git LFS,或者您可以直接使用常规的构件管理系统来代替。无论如何,不要盲目地将大型 blob 推送到 Git 存储库。

第 4 步:复杂的依赖关系

Perforce 工作副本实际上可能映射到来自多个模块的数据的只读副本中。在 Git 中,这要么使用子模块、子树,要么利用 CI/CD 或构件管理系统来完成。这里没有简单的答案,但是一些数据导入工具可以建模 Git 代码存储库之间的子模块关系。要更深入地了解如何使用子模块或子树,您可以在这里阅读每个子模块或子树:https://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/

第 5 步:如何在迁移期间组建团队

因此,您的 Perforce 服务器有来自 10 个团队的 100 个项目。您已经制定了迁移策略和工具集。安排维护窗口然后开始!

呃...不。

请记住,切换 SCM 工具既关乎开发人员,也关乎数据。您需要考虑人员、流程和时间表——不要想着一蹴而就,风险太大了。

在实际迁移阶段,您需要考虑项目计划。(现在可能是尝试新的 Jira 工作流的好时机…)以下是一些您可以了解的选项。

  • 逐个团队和逐个项目迁移。目标是在冲刺或计划增量开始时,当您有时间适应时,开始一个项目和团队。
  • 逐步迁移。在周末导入所有数据,但随着时间的推移,让团队慢慢完成向 Git 的切换。通过重新运行导入工具定期提取增量。尽管更为复杂,但如果您在团队之间存在依赖关系,而早期采用者至少需要 Git 中的最新快照才能为他们的 CI/CD 管道提供信息,这种策略还不错。
  • 在一段时间内同时使用两个系统。虽然不适合胆小的人,但使用 Git Fusion 进行双向数据交换在技术上是可行的,只要您没有做会让数据转换器感到困惑的复杂操作。

最后,向团队传达更改——动机、原因以及如何做到这一点的一系列步骤。选择一支由在整个软件开发生命周期中经验丰富的工程师组成的“早期采用者”团队,让该团队成为其他团队的榜样。让 Git 拥护者在员工遇到困难时为他们提供帮助。做出微小的、易于理解的迭代更改将有助于这一流程取得成功。

第 6 步:镜像和集群

Perforce 有一个简单但有效的系统,用于将数据镜像到远程站点,以减少延迟的影响。它有一个更复杂的系统,用于运行一组用于只读集群的本地镜像。尽管 Git 根本不关心延迟,但如果您在全球范围内运行,您应该在 Bitbucket Data Center 中同时进行集群和镜像,这将大大缩短全球团队的克隆时间。

第 7 步:ALM 工具

现在有个好消息——当您从 Perforce 迁移到 Git 时,您的 ALM 工具堆栈有很多选择。几乎所有开发人员和 ALM 工具都可以使用 Git,当然,Bitbucket 可以让您与 Jira 和 Bamboo 完美集成。过渡到 Git 时,您可以探索 Bamboo 功能,例如利用功能分支工作流程的规划分支

第 8 步:定义成功

那么,在从 Perforce 迁移到 Git 的过程中,您究竟如何衡量成功呢?在许多迁移项目中,我们往往过于关注数据传输的保真度。但这不是一个有用的指标,原因有很多。很可能您永远无法在 Git 中获得与 Perforce 这样的集中式 SCM 系统中发生的情况完全相同的逐位历史记录。

更实用的方法是使用 CI/CD 进行验证。一旦您将您的 CI/CD 管道从 Perforce 切换到 Git,所有测试还能通过吗?您还能部署您的软件吗?如果您所有重要的旧版本还能通过您的 CI/CD 管道,那么是时候宣布胜利了!

总结

所以现在您已经明白了为什么会从 Perforce 转移到 Git,以及如何真正实现这一目标。下一步是选择 Git 解决方案。如果您要从 Perforce 切换到游戏开发,了解为什么游戏开发人员喜欢 Bitbucket

准备好了解 Git 了吗?

试用本交互式教程。

立即开始