A step-by-step guide to migrating from Perforce to 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 存储库
查看解决方案
了解 Bitbucket Cloud 的 Git
- 安装 Git Fusion
- 设置正确的数据视图，包括分支结构
- 使用任何 Git 客户端从 Git Fusion 克隆
- 将您的代码存储库推送到 Bitbucket
Hands-on example *In order to work through this example you’ll need a Perforce server with Git Fusion already operational.* Let’s say that you have a Perforce project living in the repository path //depot/acme/… (in Perforce depot view syntax). It has three branches: - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… Keep in mind that with Perforce you see branches as additional directories in the tree. Your first step is to configure Git Fusion so that it understands the branching relationship in Perforce. To do this, you create a repo configuration file: [@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/… … Submit this file to Perforce under the path //.git-fusion/repos/acme/p4gf_config Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, clone from Git Fusion: git clone https:///acme cd acme git remote add bitbucket git push –u --all bitbucket git push --tags Bitbucket That’s it! You should now see the imported history in Bitbucket.现在，这可能并不能始终为您提供 Perforce 数据的 100% 忠实副本。有些 Perforce 操作，比如部分合并，在 Git 中没有等效操作。但总而言之，这种方法可以让您轻松掌握大部分历史记录。
请记住，从传统 SCM 保留过去 10 年的分支历史记录并不意味着您必须继续使用相同的工作流程。值得注意的是，您应该考虑采用 Git Flow 等功能分支工作流程作为实际的第一步。
优点和缺点
- 需要最多的设置工作和运行时间
- 保留最多的历史记录（允许您关闭旧版 Perforce 服务器）
- 保留历史记录中的传统分支模型
移动 Perforce 数据选项 2：重新开始
另一种选择是重新开始。忘掉那些笨重的历史记录：只需在 Perforce 中提取与您的项目相对应的每个分支的头部（尖端），然后将这些东西签出到新的空 Git 代码存储库中即可。（这意味着您已使用所需数据的正确“视图”定义了 Perforce 工作区。）
这是最简单和最快的技术。无论您的 Perforce 历史记录有多复杂，您的新 Git 代码存储库都是精简出色的。您有机会启动基于 Git 的新工作流程，而不会累积任何难题。
主要缺点是，您可能要让旧的 Perforce 服务器保持只读模式，以防有人出于任何原因需要深入研究历史代码。这不会花费您任何许可费，但它确实意味着您要让旧服务器存活一段时间。
**Hands-on example** Go into your Perforce workspace (the directory where the main branch of your project data is checked out) and run: p4 sync This fetches the latest revision of your files. Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, create a new Git repo in your workspace and push to Bitbucket: git init . git remote add origin git push –u --all origin git push --tags origin You should now see the latest snapshot of your code as the first commit in your new Bitbucket project.优点和缺点
- 快速简单
- 重新设计分支模型和工作流程
- 用于只读访问的传统 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 步：复杂的依赖关系
A Perforce working copy may actually map in read-only copies of data from several modules. In Git, this is done either using submodules, subtrees, or by leveraging CI/CD or artifact management systems. There’s no easy answer here, but some data import tools can model a submodule relationship between Git repos. For a more in depth look on how to use submodules or subtrees, you can read about each here: https://www.atlassian.com/git/tutorials/git-subtree.
第 5 步：如何在迁移期间组建团队
因此，您的 Perforce 服务器有来自 10 个团队的 100 个项目。您已经制定了迁移策略和工具集。安排维护窗口然后开始！
呃...不。
请记住，切换 SCM 工具既关乎开发人员，也关乎数据。您需要考虑人员、流程和时间表——不要想着一蹴而就，风险太大了。
在实际迁移阶段，您需要考虑项目计划。（现在可能是尝试新的 Jira 工作流的好时机…）以下是一些您可以了解的选项。
- 逐个团队和逐个项目迁移。目标是在冲刺或计划增量开始时，当您有时间适应时，开始一个项目和团队。
- 逐步迁移。在周末导入所有数据，但随着时间的推移，让团队慢慢完成向 Git 的切换。通过重新运行导入工具定期提取增量。尽管更为复杂，但如果您在团队之间存在依赖关系，而早期采用者至少需要 Git 中的最新快照才能为他们的 CI/CD 管道提供信息，这种策略还不错。
- 在一段时间内同时使用两个系统。虽然不适合胆小的人，但使用 Git Fusion 进行双向数据交换在技术上是可行的，只要您没有做会让数据转换器感到困惑的复杂操作。
最后，向团队传达更改——动机、原因以及如何做到这一点的一系列步骤。选择一支由在整个软件开发生命周期中经验丰富的工程师组成的“早期采用者”团队，让该团队成为其他团队的榜样。让 Git 拥护者在员工遇到困难时为他们提供帮助。做出微小的、易于理解的迭代更改将有助于这一流程取得成功。
Step 6: Mirrors and clusters
Perforce 有一个简单但有效的系统，用于将数据镜像到远程站点，以减少延迟的影响。它有一个更复杂的系统，用于运行一组用于只读集群的本地镜像。尽管 Git 根本不关心延迟，但如果您在全球范围内运行，您应该在 Bitbucket Data Center 中同时进行集群和镜像，这将大大缩短全球团队的克隆时间。
Step 7: ALM tools
现在有个好消息——当您从 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。
分享此文章
下一主题
推荐阅读
将这些资源加入书签，以了解 DevOps 团队的类型，或获取 Atlassian 关于 DevOps 的持续更新。
Bitbucket 博客
DevOps 学习路径
