Git ユーザーが切り替えるべき理由
Git は、オープンソースで柔軟性が高く、無料で使用できることから人気の VCS ですが、現代テクノロジーに精通していないユーザーにとっては難しく感じることもあります。アーティストが問題に直面すると、その解決にプログラマーが必要になります。アーティストが使っているツールには対応せず、ゲーム開発につきもののサイズの大きなバイナリファイルの重さに負けてしまいます。
Sycoforge 制作『Return to Nangrim』
Git ユーザーが Unity のバージョン管理から得られるメリット
Unity Plastic SCM は、ゲーム開発のために構築されています。Git からアップグレードすることで得られるものは、次のとおりです。
サイズの大きなリポジトリやバイナリファイルでも高速に処理する
Plastic は、5 TB を超えるリポジトリにも対応し、他のソリューションと比較してチェックインと更新を 5 倍から 8 倍高速で処理します。
アーティストとのコラボレーションを改善する
アーディストは、ファイルをロックする機能を備えた使いやすいワークフローである Gluon を介して、Plastic SCM を独立して使用できます。プログラマーは、完全なブランチング機能とマージ機能を備えた標準のワークフローを引き続き使用できます。
集中型または分散型で作業する
VCS を選択することで、集中型と分散型のどちらで作業するかが決まることがよくあります。Plastic は両方に対応しており、Git スタイルのワークフローのスピードとパワー、Perforce のようなスケーラビリティが得られます。
柔軟性を高めてメンテナンスをシンプルにする
Plastic SCM は追加設定なしで複数のワークフローやサイズの大きなファイルに対応するため、冗長なシステムやアドオンを維持する必要がなくなります。ツールチェインの無駄を省き、高いパフォーマンスを発揮できるよう維持しましょう。
Unity の DevOps ソリューションは、プログラマーにとって幅広い機能が備わっていながらも、アーティストにとって合理的に保たれています。何か足りていないものがある場合は、Unity の DevOps ロードマップでご確認ください。
時間を節約してタスク切り替えを最小限に抑える
Unity のコードアウェアなマージ技術である SemanticMerge を使用すると、移動されたコードを追跡し、関連する変更にのみ集中できるようになります。構文を解析することで、通常であれば手動でのマージが必要になる 16% から 30% のコードのマージを自動化し、ワークフローの邪魔になるマージの競合を大幅に減らします。
Plastic SCM はリファクタリングを解析し、メソッドなどのコードの部分が（複数のファイル間を含めて）移動されているかどうかを評価します。これにより、最も重要な変更にのみ注目してレビューすることができます。C#、Java、VB.NET などに対応します。
.jpg?itok=y1BFjDfF)
Git クライアントとして使用する
Plastic SCM の GitSync を使用すると、Plastic と Git 間で双方向同期を実行できます。Plastic は Git のネットワークプロトコルと通信し、リモートの Git サーバーに対してパッケージとマージのプッシュ/プル（またはその逆）を行います。これにより、Plastic GUI を Git クライアントとして使用できます。Plastic と Git の構造は多少類似しているところがあるため、その間ですべての変更セット、ブランチ、マージを交換することができます。
高速なインポートとエクスポート
Plastic には fast-import コマンドと fast-export コマンドが実装されており、Git 側の対応するコマンドと完全な互換性があります。これらのコマンドは、Git から Plastic にプロジェクトをインポートする以外にも、万が一 Plastic から移行する必要がある場合に、それを安全に行うのにも使用されます。日常業務においては、GitSync を使用するほうが簡単です。
Git エコシステムを活用する
Git のエコシステム内の任意のツールを、そのツールのネイティブの Git 機能を使用して、Plastic にすぐに接続できます。こうすることで、Plastic を使用しているチームが、Git のために特別に開発されたすべての DevOps、CI、プロジェクト管理の統合のメリットを享受できます。
GitServer は、サーバー側の GitSync に対応するものです。Git プロトコルを使用して Plastic SCM をリポジトリに対応させることで、Git との相互運用性ループを閉じます（Git と HTTP に対応しています）。
さまざまなゲームでの活用事例
Goodbye Volcano High
作業者自身がオーナーである協同組合型のスタジオがどのようにして制作プロセスにてアーティストとエンジニアの足並みを揃えさせているのでしょうか？KO_OP が Plastic SCM をどのように活用してコラボレーションを強化したかをご覧ください。
Return to Nangrim
Sycoforge が Unity のツールをどのように活用して拡大するプロジェクトのスコープを管理し、ゲーム開発のスピードアップとイテレーションにプレイヤーのフィードバックを生かしているかをご覧ください。
Subnautica
Unknown Worlds が『Subnautica』に命を吹き込むためになぜ Unity と Plastic SCM を選んだのか、その理由をご紹介します。
よくあるご質問
Plastic も DVCS です。そのため、まずコミット（チェックイン）を行ってから、変更をリモートリポジトリにプッシュするという、同じワークフローを使用します。Plastic では、必要に応じて集中型で作業することもできます。SVN のように、中間クローンなしで直接チェックインを実行することも可能です。
プログラマーにとってのお気に入りは DVCS でしょうが、アーティストやデザイナーにはおそらく集中型が好まれます。
はい。Plastic でのあらゆる操作は、GUI から目で見ながら行うことができます。ブランチングやマージに関わるすべての操作は、ブランチエクスプローラーを使用して行います。
はい。部分レプリカを作成することもできます。つまり、あるブランチをその親やマージ元なしでプルし、変更を加えてプッシュバックできるということです。
Plastic で複製されたリポジトリで作業を開始するのに、完全なリポジトリの「クローンを作成する」必要はありません。部分レプリカと呼ばれるものを実行し、そのリポジトリで作業を行い、新しい変更を加え、戻すだけです。このほうがはるかに高速です。
これは、深度が制限されているものの、プッシュバック可能なシャロークローンに相当します。
Plastic のマージ機能のほうがより優れています。Plastic のマージエンジンは、Git では対応できないような移動や名前の変更も処理できます。Plastic には独自の差分ツールやマージツールも揃っています。
Plastic は膨大なサイズのファイルも処理できます。RAM に収まるサイズが上限ではありません。Plastic は膨大なサイズのリポジトリにも対応します。
「リモート」は Plastic には存在しません。必要なブランチを必要なリポジトリに対してプッシュおよびプルするだけです。最初にリモートを定義する必要はありません。
Plastic SCM のサブモジュールは Xlink と呼ばれます。これは、サブモジュールの大幅に強化かつ簡略化されたバージョンです。Xlink を作成するのは簡単で、GUI に完全に対応しており、サブモジュールには更新という手間のかかるプロセスがありますが、Xlink にはありません。参照を手動で管理できます。Xlink が設定されたディレクトリの下のブランチは自動的に作成されるため、複数のリポジトリが存在するシナリオでの機能ブランチの作成が非常に簡単になります。
Git ベースのバージョン管理には、幅広い機能が備わっており、コミュニティのサポートを受けられる一方で、Plastic SCM はさまざまなワークフローに柔軟に対応し、追加設定なしでサイズの大きなファイルを処理できます。ある組織で機能するものが別の組織でも機能するとは限りません。自分の組織にとって何がベストかを評価するヒントについては、こちらのブログで確認してください。
Plastic SCM は Git ではありませんが、Git ベースのシステムのように分散型バージョン管理（DVCS）を可能にします。Plastic SCM には Git のすべての強みに加え、サイズの大きなファイルのサポート、一貫性のある GUI、ACL ベースのパーミッション、膨大なサイズのリポジトリの処理、強力なマージ機能、部分レプリカ、セマンティック差分などが備わっています。