バージョン管理システム（VCS）を使用すると、チームが取り組んでいるプロジェクトのソースコードをバックアップおよびアーカイブすることができます。これにより、リポジトリのレビューと編集が容易になり、ビルドを破損するようなエラーが発生した際に以前のバージョンに簡単に復元することができます。

バージョン管理は、ソースコードやアセットに対するアップデートを追跡して管理する体系的なプロセスです。バージョン管理システムは効率的なワークフローの基盤であり、プログラマー、アーティスト、その他チームメンバーにとって信頼できる唯一の情報源として機能する一方で、各自が独立して共有コードベースに貢献できるようにします。また、これらはセーフティネットとしても機能し、開発中に壊滅的なエラーが発生した場合にコードのアップデートを「取り消す」ことができます。

チームの規模や地理的分布などの要因は、ゲーム開発者がどのバージョン管理システムを実装すべきか選択に影響を及ぼす場合があります。個人開発者にとってはローカルソリューションで十分であるかも知れませんが、チームの規模が大きくなると、さまざまなタイムゾーンや地理的地域にわたってコラボレーションを行うのに役立つよう、より堅牢でスケーラブルなバージョン管理システムを探す必要が出てきます。

またバージョン管理は、ブランチの作成もサポートします。ブランチとは、VCS 内で管理されるコードの単一コピーのことです。ブランチを作成することで、開発者やその他のチームメンバーが別個のストリーム内で互いに独立して作業を進めることができます。バージョン管理は、開発者が共有コードベース内で協力して同期を保ちながら作業を進めるのを支援します。

バージョン管理システムは DevOps の中核を成し、チームがプロジェクトのソースコードに協力して取り組み、短時間でイテレーションを行えるようにします。

バージョン管理を使用することで、常にバックアップが確保されます。個々のプロジェクトのアップデートは、メインのソースコードにマージされる前に、「コミット」と呼ばれる単一のグループに定期的に収集されます。バージョン管理ソフトウェアは、各プロジェクトファイルに加えられたすべての変更を追跡するのに不可欠です。ミスやリグレッションが発生した場合、ユーザーはそのファイルの前のバージョンにほぼ一瞬で戻ることができます。また、バージョン管理はすべての変更、変更を加えたユーザー、各変更のすべてのイテレーションをログに記録します。バージョン管理システムがあれば、すべての関係者とチームメンバーが数多くのファイルで同時かつシームレスに作業をすることができます。バージョン管理システムを使用すると、コードに加えたすべての編集や変更を 1 つの一元化されたリポジトリにマージすることができます。

バージョン管理システムを使用すると、プロジェクトの全履歴にアクセスし、ミスを取り消すことができるので、バグの追跡や以前に削除した機能を復元することが簡単になります。

バージョン管理システムで新しいリポジトリを作成すると、メインブランチが開きます。これは、メインブランチまたはトランクマスターと呼ばれます。トランクマスターはメインのコードベースがパイプラインに入る場所で、その後そこでコンパイルされ、エンドユーザーに展開されます。

さて、ブランチとは一体何なのでしょうか？ブランチングとは、マスターブランチからコードをフォークするプロセスのことです。これにより、開発者はメインにコミットすることなく、コードに独自の変更を加えることができます。ブランチを使用することで、開発者は単一のサーバーに関するファイルの完全な履歴を持っておく必要がなくなります。代わりに、コードに対して経時的に加えた変更の全履歴を保持することができます。その後、バージョン管理システムではそのような別個のブランチを取り、それらをマージしてメインブランチに戻すことができます。開発者がタスクブランチをメインにマージする準備ができていない場合は、変更を別のブランチにコミットし、都合の良いときにそれをメインブランチにマージすることができます。

コードの競合やビルドの破損を回避するには、適切なブランチング戦略が不可欠です。幸いなことに、優れたバージョン管理システムのおかげで、コードがメインの統合ブランチにコミットされた後でも、チームはメインブランチと簡単に同期し、潜在的なコードの競合を修正することができます。

分散型バージョン管理システムを使用すると、メインサーバーに接続せずに、チェックイン、ブランチ作成、マージを行うことができます。各貢献者は、クラウドに保存されているリポジトリのクローンから作業します。主な利点は、低速なネットワークや VPN について心配することなく、チームメイトが各自で作業し、作業スピードを高めることができる点です。プロジェクトをオフラインで作業することもできますが、アップデートをプッシュまたはプルするにはインターネット接続が必要です。

分散型バージョン管理システムでは、特に変更履歴が広範囲にわたる大規模なプロジェクトで、プロジェクト履歴全体をダウンロードする必要がある場合に、待ち時間が長くなる可能性があります。大量のバイナリファイルを扱うスタジオは、空き容量がすぐに埋まってしまうため、ストレージの使用状況を注意深く監視する必要があります。

高い柔軟性を求めており、生産力が高くなるポテンシャルを秘めているスタジオは、分散型バージョン管理を採用することを検討してください。

集中型バージョン管理システムは、チェックイン/プッシュワークフローを使用してメインサーバーに接続します。ソースコードに対する変更つまりアップデートは、新しいバージョンとしてリポジトリに自動的に保存されます。集中型バージョン管理システムには、複数のマシンにリポジトリのクローンを作成する必要のない強力なブランチ作成機能とマージ機能が備わっています。そういった意味で、潜在的により安全です。

集中型バージョン管理システムには、ネットワーク接続が必要です。チーム全員が 1 つのサーバーに格納されている単一のバージョンに紐付けられているため、サービスの中断が発生すると大幅な速度の低下につながるおそれがあります。集中型バージョン管理のもう 1 つの欠点は、拡張性が低いことです。プロジェクトに貢献する開発者の数が多ければ多いほど、安定した環境で変更をプッシュする機会が減り、マージの競合などの問題につながるおそれがあります。

設定が簡単で使いやすいバージョン管理システムに関心をお持ちの方は、集中型ワークフローの採用を検討してください。

ローカルバージョン管理システムは、最もシンプルな形式のバージョン管理システムであり、チームよりも主に個人開発者によって使用されます。ローカルバージョン管理では、プロジェクトのすべてのデータが 1 台のコンピューターに保存され、プロジェクトのファイルに加えられた変更はパッチとして保存されます。各パッチには、前のパッチ以降に実装されたアップデートのみが含まれています。プロジェクトのある特定のバージョンで問題が発生した場合は、パッチのコレクション全体を調べ、ある特定の時点でプロジェクトのファイルがどのような見た目であるかつなぎ合わせることで、問題を診断する必要があります。

これらは 1 台のコンピューターに紐付けられているため、ローカルバージョン管理システムは、分散型システムや集中型システムよりも本質的に柔軟性が低くなります。チームメイト同士でのコラボレーションは難しく、データベースが危険にさらされた場合に、失った情報を復元することは不可能ではないにしても難しくなるおそれがあります。

一般的に、最初はローカルバージョン管理で問題ありませんが、チームの規模が拡大するのに合わせて（たとえ 1 人から 2 人に増えるだけでも）、分散型または集中型で作業を進め始めることをお勧めします。