Perforce から Git への移行

As we discussed in the previous article, Git is now the de facto choice for SCM for just about any type of digital development. But if you have years of valuable history stored in Perforce, you are probably weighing the cost of switching. In this article we’ll tackle those concerns head-on, and tell you how to migrate data to Git. We’ve broken the Perforce to Git migration process down to 8 steps:

ステップ 1:Perforce データの移動

Perforce から Git にデータを移行するには、2つの一般的なアプローチがあります。移行の前に、ソフトウェアプロジェクトの取り扱い方について、Perforce と Git の基本的な違いを考慮する必要があります。

Perforce サーバは、それぞれ独自の分岐モデルを持つ数十から数百の異なるソフトウェアプロジェクトを保持できます。開発者は、作業コピーに入れるファイルを Perforce サーバに伝える「ビュー」を定義します。一方、Git リポジトリは通常、単一のソフトウェアプロジェクトとそのブランチとタグを保持しています(大きな一体型の Git リポジトリも存在します)。通常、リポジトリを複製して、サブモジュールやサブツリーをチェックアウトします。

The question of moving the data, then, has two parts: how to extract data from Perforce, and how to translate that into an equivalent set of Git repositories.

Perforce データの移動オプション 1:Git Fusion の使用

Perforce でデータの履歴全体を保存したい場合は、Perforce 独自の Git Fusion ツールを使用して、Perforce サーバーのセクション (単一プロジェクト) を Git リポジトリに抽出できます。基本的には以下の手順を実行します。

  • Git Fusion をインストールします。
  • Set up the correct views of your data, including the branching structure
  • いずれかの Git クライアントを使用して Git Fusion から複製を作成します。
  • 自分のリポジトリを Bitbucket にプッシュします。
*この例を実行するには、Git Fusion がすでに稼働している Perforce サーバーが必要です。*
Perforce プロジェクトがリポジトリパス //depot/acme/… (Perforce ディポ表示構文) にあるとします。そこには3つのブランチがあります。
- //depot/acme/main/…
Perforce では、ブランチはツリー内の追加ディレクトリとして表示されます。
最初のステップは、Perforce の分岐関係を理解できるように Git Fusion を設定することです。これを行うには、リポジトリ設定ファイルを作成します。
description = Acme project
charset = utf8
git-branch-name = master
view = //depot/acme/main/… …
git-branch-name = r1.0
view = //depot/acme/r1.0/……
git-branch-name = r1.1
view = //depot/acme/r1.1/……
Submit this file to Perforce under the path //.git-fusion/repos/acme/p4gf_config
ここで、通常の Bitbucket 管理ツールを使用して、acme という名前の空のプロジェクトを Bitbucket に作成します。通常の標準に従ってアクセス制御とチームメンバーを設定できます。次に、Git Fusion から複製します。
git clone https://<git fusion server url>/acme
cd acme
git remote add bitbucket <bitbucket project URL>
git push –u --all bitbucket
git push --tags Bitbucket
これで完了です。インポートされた履歴が Bitbucket に表示されているはずです。

これで Perforce データを常に 100% 忠実にコピーできるわけではありません。部分的マージのように、一部の Perforce 操作は、相当する操作が Git に存在しません。しかし、全体として見れば、この方法により多大な労力をかけずに履歴のほとんどを取得することができます。

既存の SCM から最近 10 年間のブランチ作成履歴を保護しても、同じワークフローを継続して使用する必要はないことを覚えておいてください。特に、実用的な第一歩として、Git Flow のようなフィーチャーブランチワークフローの採用を検討すべきです。

Pros and cons

  • ほとんどのセットアップ作業とランタイムが必要
  • ほとんどの履歴を保持 (従来の Perforce サーバをシャットダウンできます)
  • 履歴に既存の分岐モデルを維持

Perforce データの移動オプション 2:新たに最初から行う

もう1つの方法はやり直すことです。これまでの入り組んだ履歴のことはすべて忘れてください。そして、プロジェクトに対応する Perforce の各ブランチの head (先端) を単に抽出し、それを新しい空の Git リポジトリにチェックインします (これは、必要なデータの正しい 'ビュー' で Perforce ワークスペースを定義したことになります)。

これは最も簡単で最速のテクニックです。Perforce の履歴がどんなに複雑であっても、新しい Git リポジトリは無駄なくすっきりとしています。蓄積された荷物なしで新しい Git ベースのワークフローを開始できます。

主な欠点としては、おそらく、誰かが何らかの理由で履歴コードを調べる必要がある場合に備えて、古い Perforce サーバを読み取り専用モードに保つ必要があることです。これにより、ライセンス料はかかりませんが、古いサーバーをしばらく維持することになります。

ご使用の Perforce ワークスペース (プロジェクトデータのマスターブランチがチェックアウトされているディレクトリ) に移動して
p4 sync
ここで、通常の Bitbucket 管理ツールを使用して、acme という名前の空のプロジェクトを Bitbucket に作成します。通常の標準に従ってアクセス制御とチームメンバーを設定できます。次に、ワークスペースに新しい Git リポジトリを作成し、Bitbucket にプッシュします。
git init
git remote add origin <bitbucket project URL>
git push –u --all origin
git push --tags origin
新しい Bitbucket プロジェクトの最初のコミットとしてコードの最新のスナップショットが表示されているはずです。

Pros and cons

  • 速くて簡単
  • 分岐モデルとワークフローの再設計
  • Legacy Perforce server used for read-only access

ステップ 2:ユーザーと権限

After the data is moved over, the next task is usually to start mapping your users and permissions into new Bitbucket projects. If you use LDAP for a user directory you’ll save some time here. Otherwise, you can easily extract a set of user accounts from Perforce using the p4 users –o command and then enter them into Bitbucket a project at a time.

Translating Perforce permissions into the equivalent Bitbucket permissions can be difficult because Perforce permissions are granular and complex, with the possibility of excluding access to individual files. This complicated permission scheme is one reason why a Perforce server can bog down – every attempt at access may cause the server to perform an expensive computation on a complicated data structure.

ほとんどの場合、通常のプロジェクト、リポジトリ、およびブランチレベルの権限を使用して、Bitbucket でより簡単な権限セットを定義するようにプロジェクトリードに依頼するほうが効率的です。Git は非常に多くの新しいワークフローオプションを提供しているため、いずれにしても権限設定を再検討したくなるでしょう。たとえば、Perforce ではブランチ作成を制限していたかもしれませんが、Bitbucket ではマスターブランチへのプッシュアクセスを制限するだけで済む場合もあります。

ステップ 3:バイナリファイル

If you stored large binary blobs in Perforce, think carefully about how you want to manage those in Git. You could try out Git LFS, or you could simply use a regular artifact management system instead. In any case you don’t want to blindly push large blobs into a Git repo.

ステップ 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:

ステップ 5:移行中にチームを構成する方法

So, your Perforce server has 100 projects from 10 teams. You’ve got a migration strategy and tool set laid out. Schedule the maintenance window and go!

Er… no.

Remember that switching SCM tools is as much about developers as it is data. You’ve got people, process, and schedule to consider – don’t try to boil the ocean in a single day. It’s too risky.

実際の移行フェーズ中にプロジェクト計画を検討する必要があります (新しい JIRA ワークフローを試してみる良い機会になるかもしれません)。検討事項は以下のとおりです。

  • チーム別やプロジェクト別に移行する。スプリントまたはプログラムインクリメントの開始時にプロジェクトとチームを開始することが目的です。これは適応する時間的余裕がある場合に適しています。
  • 漸次移行する。週末にすべてのデータをインポートしておき、Git へのチームの移行は時間をかけてゆっくりと完了させます。定期的にインポートツールを再実行して差分をピックアップします。この計画の場合複雑さは増しますが、チーム間に依存関係があり、早期導入者が CI/CD パイプラインをフィードするために少なくとも Git で撮った最近のスナップショットを必要とする場合は適しています。
  • 一定期間、同時に両方のシステムを使用する。気弱な人向きではありませんが、技術的には、Git Fusion を使用して双方向のデータ交換を行うことは可能です。ただし、データ変換で混乱を招くような複雑な操作を行っていない場合に限ります。

Lastly, invest in communicating the changes to the team – the motivation, the why, and a series of steps for how to do it. Pick an “early adopter” team with engineers experienced in the entire software development lifecycle, and have that team be a model for the others. Find Git champions to assist people when they have a difficulty. Making small, understandable, iterative changes will help this process be successful.

ステップ 6:ミラーとクラスタ

Perforce には、データをリモートサイトにミラーリングして待ち時間の影響を軽減するためのシンプルで効果的なシステムがあります。読み取り専用クラスタリングのために一群のローカルミラーリングを実行する場合は、より複雑なシステムが用意されています。待ち時間は単に Git の問題ではありませんが、世界中でオペレーションを行なっている場合は、クラスタリングとミラーリングの両方について Bitbucket Data Center を調べる必要があります。これにより、グローバルチームのために複製する時間が大幅に短縮されます。

ステップ 7:ALM ツール

And now for some good news – you’ve got a lot of choices for your ALM tool stack when you move from Perforce to Git. Pretty much every developer and ALM tool out there works with Git, and of course Bitbucket gives you great integration with JIRA and Bamboo. As you transition to Git, you can explore Bamboo features such as Plan Branches that take advantage of a feature branch workflow.

ステップ 8:成功の定義

Perforce から Git への移行の間、どのようにして成功を正確に測定するのでしょうか。多くの移行プロジェクトでは、データ転送の忠実性に重点を置く傾向があります。しかし、これは多くの理由から有用なメトリックではありません。Perforce のような集中型 SCM システムで生じたこととまったく同じ内容を、Git においてビット単位の履歴で取得することは決してできないでしょう。

A more practical approach is to use CI/CD for verification. Once you switch your CI/CD pipeline from Perforce to Git, do all your tests still pass? And can you still deploy your software? If all of your important older builds can still pass through your CI/CD pipeline, then it’s time to declare victory!


So now you’ve seen why there’s movement from Perforce to Git, and how to actually get there. The next step is to choose a Git solution. If you are switching from Perforce for game development, see why game developers love Bitbucket.

Git を学習する準備はできていますか?