Gitユーザー向けのPerforce？
多くの「Git for Perforceユーザー」のドキュメントがありますが、その逆はほとんどないようです。
私は以前にGitを使用したことがありますが、最近Perforceを頻繁に使用しなければならない仕事を開始しました。私がGitで使っていた概念は、Perforceにはまったくマップされていないようです。
Gitに慣れている人のためにPerforceを使用するためのヒントをまとめることに興味がある人はいますか？
これは私が過去数週間にわたってオンとオフに取り組んできたものです。まだ進化していますが、役に立つかもしれません。私はPerforceの従業員です。
Gitユーザー向けのPerforceの紹介
GitからPerforceに、またはPerforceからGitに移行するのは簡単ではないと言うことは、控えめな表現です。表面上は同じことを行う2つのツールであるため、それらのアプローチはこれ以上違いはありません。この簡単な記事は、Gitから来た新しいPerforceユーザーが、彼らがいる新しい世界を理解するのに役立つでしょう。
飛び込む前の短い迂回。 Gitを好む場合は、PerforceでGitを非常にうまく使用できます。 Perforceサーバーとの同期を維持するGitリポジトリを生成するGit Fusionと呼ばれるツールを提供しています。 GitとPerforceの人々は、同じコードで調和して作業できますが、ほとんどの場合、同僚がバージョン管理を選択しても影響を受けません。 Git Fusions 13.3は Perforce Webサイト から入手できます。 Perforce管理者がインストールする必要がありますが、インストールするとリポジトリのスライス機能がGitユーザーとして非常に便利であることがわかります。
管理者にGit Fusionのインストールを説得できない場合、Git自体にGit-P4というPerforceバインディングが付属しており、Gitを使用してPerforceワークスペースでファイルを変更および送信できます。詳細については、以下を参照してください。 https://git.wiki.kernel.org/index.php/GitP4
まだここ？それでは、Perforceを見てみましょう。
整理する用語の違い
詳細に入る前に、GitとPerforceの用語の違いを簡単に説明する必要があります。
1つ目はcheckoutです。 Gitでは、これが特定のブランチから作業領域にコードのコピーを取得する方法です。 Perforceでは、これをコマンドラインまたはGUI P4Vの「Get Latest Revision」からsyncと呼びます。 Perforceは、P4VのWordcheckoutまたはコマンドラインのp4 editを使用して、バージョン管理システムからファイルを変更することを意味します。このドキュメントの残りの部分では、PerforceのWordの意味でチェックアウトを使用します。
2つ目はGitcommit対Perforcesubmitです。 Gitでコミットする場所は、Perforceで送信します。すべての操作は共有のPerforceバージョン管理サービスに対して行われるため、Perforceにはgit Pushに相当するものがありません。同様に、pullはありません。上記のsyncコマンドは、ファイルの取得を処理します。以下で簡単に説明するP4Sandboxツールを使用することを選択しない限り、Perforceに純粋なローカル送信の概念はありません。
Perforceの重要な概念
Perforceを2つの重要な概念に単純化する場合、デポとワークスペースに焦点を合わせます。 Perforceデポは、Perforceサーバーに存在するファイルのリポジトリです。 Perforceサーバーには任意の数のデポを含めることができ、各デポには任意の数のファイルを含めることができます。多くの場合、Perforceユーザーはデポとサーバーを同じ意味で使用しますが、それらは異なります。 Perforceサイトでは複数のサーバーを選択できますが、ほとんどの場合、すべてのファイルは1つのサーバーにあります。
PERFORCEワークスペースまたはクライアントは、PERFORCEサーバー内の一連のファイルをユーザーのファイルシステム上の場所にマップするシステム内のオブジェクトです。すべてのユーザーは、使用するマシンごとにワークスペースを持ち、多くの場合、ユーザーは同じマシンに対して複数のワークスペースを持ちます。ワークスペースの最も重要な部分は、ワークスペースのマッピングまたはビューです。
ワークスペースビューは、ローカルマシンにマッピングされるデポ内のファイルのセットを指定します。これは重要です。なぜなら、サーバー上で利用可能なすべてのファイルが必要になるわけではないからです。ワークスペースビューでは、関心のあるセットのみを選択できます。ワークスペースは複数のデポのコンテンツをマップできますが、1つのサーバーのコンテンツしかマップできないことに注意することが重要です。
この点でPerforceとGitを比較するには、Gitを使用して、関心のあるGitリポジトリのセットを選択します。各リポジトリは一般に、関連ファイルのみを含むように厳密にスコープされます。これの利点は、ユーザー側で行う構成がないことです。気にすることのgit cloneを行うと完了です。これは、1つまたは2つのリポジトリのみを操作する場合に特に便利です。 Perforceでは、少し時間をかけて必要なコードを選択する必要があります。
多くのPerforceショップは、ワークスペースビューを自動的に生成できるストリームを使用するか、スクリプトまたはテンプレートワークスペースを使用してビューを生成します。同様に、多くのユーザーがユーザーに自分のワークスペースを生成させます。 1つのワークスペースで多数のモジュールをマップできることの1つの利点は、1つのチェックインで複数のコードモジュールを簡単に変更できることです。あなたのチェックインに同期する同様のクライアントビューを持つ人は、すべてのコードが正しい状態にあることが保証されます。ただし、これによりコードが過度に依存する可能性もあります。 Gitを強制的に分離すると、モジュール性が向上します。ありがたいことにPerforceは厳格なモジュール性もサポートできます。このツールをどのように使用するかは、すべて問題です。
ワークスペースを選ぶ理由
Gitから来たとき、ワークスペース全体のコンセプトは価値があるよりもはるかに面倒だと感じるのは簡単だと思います。いくつかのGitリポジトリのクローンを作成するのに比べて、これは間違いなく真実です。ワークスペースが輝いている場所であり、Perforceが長年にわたってビジネスを続けている理由は、ワークスペースが開発者にとって数百万のファイルプロジェクトを削減する素晴らしい方法であると同時に、すべてのソースを簡単に構築およびリリースできるようにするためです1つの信頼できるソース。ワークスペースは、Perforceが同様に拡張できる主な理由の1つです。
ワークスペースは、ディポ内のファイルのレイアウトとユーザーのマシン上のレイアウトが必要に応じて異なる可能性があるという点でも優れています。多くの企業は、会社の組織を反映するようにデポを編成しているため、ビジネスユニットまたはプロジェクトごとにコンテンツを簡単に見つけることができます。しかし、彼らのビルドシステムは、この階層についてあまり気にすることができませんでした。ワークスペースでは、ツールにとって意味のある方法でデポ階層を再マップできます。また、コードが非常に特殊な構成である必要があり、人間をまったく混乱させる、非常に柔軟性のないビルドシステムを使用している企業がこれを使用しているのを見ました。これらの企業は、ワークスペースを使用して、構築ツールが必要な構造を取得しながら、人間がナビゲート可能なソース階層を持つことができます。
Perforceのワークスペースは、ユーザーが操作したいファイルのセットをマッピングするために使用されるだけでなく、サーバーがユーザーが同期した各ファイルのリビジョンを正確に追跡するためにも使用されます。これにより、システムは、ファイルをスキャンして更新する必要があるファイルを確認することなく、同期時に正しいファイルのセットをユーザーに送信できます。大量のデータの場合、これはパフォーマンスの大幅な向上につながります。これは、非常に厳格な監査ルールを持つ業界でも非常に人気があります。 Perforce管理者は、どの開発者がどのファイルを同期したかを簡単に追跡および記録できます。
Perforceワークスペースのフルパワーの詳細については、 P4の設定 を参照してください。
明示的チェックアウトと暗黙的チェックアウト
GitからPerforceに移行するユーザーにとって最大の課題の1つは、明示的なチェックアウトの概念です。 Git/SVN/CVSのワークフローでファイルを変更し、バージョン管理システムに自分のしたことを探すように指示することに慣れている場合は、非常に痛みを伴う移行になります。
良いニュースは、そのように選択した場合、PerforceでGitスタイルのワークフローを使用できることです。 Perforceでは、ワークスペースに「allwrite」オプションを設定できます。これにより、すべてのファイルが書き込み可能なビットが設定された状態でディスクに書き込まれる必要があることがPerforceに通知されます。その後、Perforceに明示的に通知せずに、必要なファイルを変更できます。行った変更をPerforceで調整するには、「p4 status」を実行します。必要に応じて、ファイルを開いて追加、編集、削除します。この方法で作業する場合、「p4 sync」ではなく「p4 update」を使用してサーバーから新しいリビジョンを取得する必要があります。 「p4 update」は同期の前に変更をチェックするため、「p4 status」をまだ実行していない場合、ローカルの変更を上書きしません。
明示的なチェックアウトを行う理由
私がよく受ける質問は、「なぜ明示的なチェックアウトを使用したいのですか？」です。一見赤面は、クレイジーなデザイン決定のように思えますが、明示的なチェックアウトにはいくつかの強力な利点があります。
明示的なチェックアウトを使用する理由の1つは、コンテンツの変更についてファイルをスキャンする必要がなくなることです。小規模なプロジェクトでは、各ファイルのハッシュを計算して差異を見つけるのはかなり安価ですが、多くのユーザーはワークスペースに数百万のファイルを持っているか、サイズが大きくないにしても数百メガバイトのファイルを持っています。これらの場合、すべてのハッシュを計算するのは非常に時間がかかります。明示的なチェックアウトにより、Perforceはどのファイルを操作する必要があるかを正確に知ることができます。この動作は、ゲーム、映画、ハードウェア業界などの大規模ファイル業界でPerforceが非常に人気がある理由の1つです。
別の利点は、明示的なチェックアウトが非同期通信の形式を提供することです。これにより、開発者は、ピアが何を処理しているか、少なくともどこで作業しているかを一般的に知ることができます。不必要な競合を避けるために特定の領域での作業を避けたい場合があることを知らせることができます。また、チームの新しい開発者がおそらく必要のないコードにさまよっているという事実を警告することもできます。編集する。私の個人的な経験では、Gitで作業するか、Perforceを使用して、私が唯一の貢献者または不定期の貢献者であるプロジェクトでallwriteを使用する傾向があります。ありがたいことに、選択はあなた次第です。
明示的なチェックアウトは、保留中のチェンジリストというPerforceの概念ともうまく機能します。保留中のチェンジリストは、作業を整理するために開いているファイルを入れることができるバケットです。 Gitでは、作業を整理するためのバケットとして異なるブランチを使用する可能性があります。ブランチは優れていますが、実際にサーバーに送信する前に、作業を複数の名前付き変更に整理できると便利な場合があります。複数のブランチまたは複数のプロジェクトを1つのワークスペースにマッピングする可能性があるPerforceモデルでは、保留中のチェンジリストにより、個別の変更を簡単に整理できます。
Visual StudioやEclipseなどの開発にIDEを使用する場合、IDEにPerforceプラグインをインストールすることを強くお勧めします。ほとんどのIDEプラグインは、編集を開始すると自動的にファイルをチェックアウトするため、自分でチェックアウトする必要がありません。
Git機能のPerforceの置き換え
git stash==>p4 shelve- git local branching ==> Perforceシェルフまたはタスクブランチのいずれか
git blame==>p4 annotateまたはGUIからのPerforceタイムラプスビュー
切断された作業
Perforceバージョン管理サービスから切断された状態で作業するための2つのオプションがあります（これはPerforceサーバーの仮の用語です）。
1）P4Sandboxを使用して完全なローカルバージョン管理とローカル分岐を行う
2）必要に応じてファイルを編集し、「p4 status」を使用して、Perforceに実行内容を通知します
上記の両方のオプションを使用すると、ファイルをロック解除する必要がないように、ワークスペースで「allwrite」設定を使用することを選択できます。このモードで作業する場合、「p4 sync」ではなく「p4 update」コマンドを使用して新しいファイルを同期する必要があります。 「p4 update」は、ファイルを同期する前にファイルの変更をチェックします。
Perforceクイックスタート
以下のすべての例は、コマンドラインを使用します。
1）Perforceへの接続を設定します
export P4USER=matt
export P4CLIENT=demo-workspace
export P4PORT=perforce:1666
これらの設定をシェル構成ファイルに固定するか、p4 setを使用してWindowsおよびOS Xに保存するか、Perforce構成ファイルを使用できます。
1）ワークスペースを作成する
p4 workspace
# set your root to where your files should live:
Root: /Users/matt/work
# in the resulting editor change your view to map the depot files you care about
//depot/main/... //demo-workspace/main/...
//depot/dev/... //demo-workspace/dev/...
2）サーバーからファイルを取得する
cd /Users/matt/work
p4 sync
3）作業したいファイルをチェックアウトして変更します
p4 edit main/foo;
echo cake >> main/foo
4）サーバーに送信する
p4 submit -d "A trivial edit"
5）p4 help simpleを実行して、Perforceで作業するために必要な基本的なコマンドを確認します。
Gitとp4の最大の違いは、既存の回答では解決されていませんが、異なる抽象化ユニットを使用していることです。
- gitでは、抽象化はpatch（別名diff、別名チェンジセット）です。 gitでのコミットは、コミットされているファイルの以前の状態と現在の状態の間で実行される
diffの出力です。 - perforceでは、抽象化はfileです。 p4のコミットは、その時点でのコミット内のファイルの完全なコンテンツです。これはチェンジリストに編成されますが、リビジョン自体はファイルごとに保存され、チェンジリストは単にファイルの異なるリビジョンをまとめて収集します。
この違いから他のすべてが流れます。 gitでの分岐とマージは簡単です。gitの抽象化の観点から、一連のパッチを順番に適用することですべてのファイルを完全に再構築できるため、2つのブランチをマージするには、ソースブランチにすべてのパッチを適用するだけですターゲットブランチのターゲットブランチには、正しい順序で存在しません（両方のブランチに重複するパッチがないと仮定します）。
PERFORCEブランチは異なります。 perforceでのブランチ操作は、あるサブフォルダーから別のサブフォルダーにファイルをコピーし、サーバー上のメタデータでファイル間のリンクをマークします。あるブランチから別のブランチにファイルをマージするには（perforceの用語でintegration）、perforceはファイルのcomplete contentを見てソースブランチの「head」と、ターゲットブランチのheadにあるファイルのcomplete content、必要に応じて共通の祖先を使用してマージします。 git canのように1つずつパッチを適用することはできません。これは、手動マージがより頻繁に発生することを意味します（そして、より痛みを伴う傾向があります）。
Perforceは非常に伝統的なリビジョン管理システム（CVS、Subversionなどに近い）であり、通常、最新の分散リビジョン管理システムよりも複雑ではないと考えられているため、おそらくそのようなドキュメントはそれほど多くありません。
コマンドを一方から他方にマップしようとするのは適切なアプローチではありません。集中型と分散型のリビジョン管理システムの概念は同じではありません。代わりに、Perforceの典型的なワークフローについて説明します。
- 編集する各ファイルで
p4 editを実行します。編集中のファイルをPerforceに伝える必要があります。新しいファイルを追加する場合は、p4 addを使用します。ファイルを削除する場合は、p4 deleteを使用します。 - コードを変更します。
p4 changeを実行して、変更セットを作成します。ここで、変更の説明を作成し、オプションで変更セットにファイルを追加または削除することもできます。必要に応じて、後でp4 change CHANGE_NUMBERを実行して説明を編集できます。- 必要に応じて、追加のコードを変更できます。他のファイルを追加/編集/削除する必要がある場合は、
p4 {add,edit,delete} -c CHANGE_NUMBER FILEを使用できます。 p4 syncを実行して、サーバーから最新の変更を取り込みます。p4 resolveを実行して、同期の競合を解決します。- 変更を送信する準備ができたら、
p4 submit -c CHANGE_NUMBERを実行します。
p4 revertを使用して、ファイルへの変更を元に戻すことができます。
ファイルが重複しない限り、複数のチェンジセットを同時に操作できます。 （Perforceクライアントのファイルは、一度に1つの変更セットでのみ開くことができます。）これは、小さな独立した変更がある場合に便利な場合があります。
別のチェンジセットですでに開いているファイルを編集する必要がある場合は、別のPerforceクライアントを作成するか、p4 shelveを使用して既存のチェンジセットを後でスタッシュできます。 （git stashとは異なり、シェルビングはローカルツリー内のファイルを元に戻さないため、個別に元に戻す必要があります。）