ゲーム開発でのバージョン管理-いつブランチすべきですか？

私は最近、プロジェクトでバージョン管理の使用を開始しました（1人でプロジェクトに取り組んでいますが）。これにより、開発プロセス全体の履歴を（問題追跡を使用して）保持するのに便利な方法であり、プロジェクトのバックアップを途中で保持することができます。

バージョン管理を使用することの機能と利点を徐々に発見するにつれて、分岐のアイデアにとらわれています。いつ行うべきですか？

新しい機能を開発するたびに、または特定のマイルストーンに達するのはたまにしかありませんか？

明らかに、単独で作業する場合、分岐はかなり役に立たないが、今は良い習慣を身につけてそれに慣れたい。

Mike McShaffryによるGame Coding Complete（ちなみに素晴らしい本です）を読んでいたとき、著者が次のような3つのブランチを維持することを勧めたとき、私は完全に迷いました。

• Main：定期的な変更が行われるメイン開発ブランチ。
• ゴールド：最後のマイルストーンに到達したゴールドブランチが保持されます。
• 研究：メインブランチに悪影響を与える可能性のあるものをテストするためのブランチ（ゲームエンジンの重要なコンポーネントの変更など）。

それはどうあるべきですか？大きなチームの開発者がいるゲーム開発の世界では、実際にどのように機能しますか？

基本的に、ゲーム開発では通常いつ分岐（およびマージ）されますか？

分岐は、VCSの機能のサポートに少し依存します（つまり、VCSがそれを簡単にするか困難にするか）。

ただし、少なくとも、プロジェクトの個別にサポートされるリリースごとにブランチが必要です。つまり、同じコードベースからビルドされた個別の製品である「ゲーム2」と「ゲーム2 +拡張」があり、パッチを当ててアップデートを発行できるようにする必要がある場合は、これらのそれぞれが必要になります。メインコードベースから離れた独自のブランチに存在するため、コアコードベースの修正をこれらの各製品に個別にマージできます。（通常、これらのブランチは、各製品がリリースされたときに、またはおそらく最初のリリースで外に出たくないコードベースで作業している人がいる場合は数日/数週間前に作成されます）

ブランチを使用するのが面倒または痛みを伴うVCS（SourceSafe、svnなど）を使用する場合、各リリース製品の「リリース」ブランチを維持し、「トランク」でメインの開発を行うのがおそらく最も幸せです。これらのリリースの修正プログラムをリリースする必要がある場合に、「トランク」から「リリース」ブランチに変更をマージする。

一方、分岐とマージ（git、Bazaar、Mercurialなど）を中心に構築された新しいVCSシステムの1つを使用している場合は、おそらく最も短時間で開発を行うことができます。 -「機能」ブランチの存続。たとえば、AIパスファインディングに取り組んでいる場合、「パスファインディング」ブランチを作成し、そこにコードを実装できます。終了したら、そのブランチを開発のメイントランクにマージし、（オプションで）作業していたブランチを削除します。このアプローチの利点は、1つのタスクを完了する必要なく、複数のタスクを同時に作業できることです。次のタスクを開始する前のタスク。

現在のホームプロジェクト（gitを使用）では、現在5つの異なる機能ブランチがアクティブになっており、さまざまな機能に取り組んでいます。それらのうちの2つは同じこと（プロファイリング）を行うための代替アプローチであり、2つは実験的なゲームメカニックアイデアであり、1つは私のAIシステムの大きなリファクタリングであり、実際にはコードが正しくコンパイルされないような方法で壊れています今。しかし、機能ブランチで参照用とバックアップ用にコミットされており、壊れても他の機能の作業を止めることはありません。これらの他の機能ブランチ（およびメインの開発トランクも）は、依然として正しくコンパイルおよび実行されます。

私の大チームによるプロのゲーム開発の経験では、私たちはまだ古い（そして商業的にサポートされている）バージョン管理システムにほとんどこだわっています。Perforceがおそらく最も一般的に使用され、Subversionがそれに続きます。私が働いていたすべての場所に、「トランク」ブランチがあり、次にすべての成果物（マイルストーン/デモ/リリース/など）ごとに個別の「リリース」ブランチがありました。時折、誰かが自分で行ったりテストしたりする大きな変更のために個人的なブランチを作成しますが、これは非常にまれで、通常は「ゲームをこの異なる物理ライブラリで実行するように変換する」などです。リリースされた製品。

すでに上記の優れた答えですが、注意すべき1つの事柄は、分岐したいときとタグを付けたいときです。

ほとんどのVCでは、タグを付けることができます（ラベル付けと呼ばれることもあります）。メジャービルドを作成するたびにタグを適用する必要があります（プレイテスト、ベータテスト、または機能の導入のいずれか）。ある種の継続的インテグレーションを使用している場合（そうする必要がある場合）、CIシステムは成功したビルドにタグを付ける必要があります。基本的に、（ブランチを作成するか、そのバージョンで何かを行った方法を確認するために）戻りたいことをするときはいつでも、タグ/ラベルを作成します。通常、低コストで簡単に追加できます。

私が強くお勧めする他のことは、資産とコードを同じバージョン管理システムに保持することです。コードのブランチ（またはタグ）を持つことは、アセットを照合（およびブランチ）できない場合、まったく役に立ちません。これは、ゲーム会社がPerforceを愛する主な理由の1つです。コードを保存するのと同じようにバイナリアートファイルを保存し、（gitとは異なり）非技術的なタイプでも理解できるのです！

ああ、いつでもコンパイル済みファイルをVCSストップにチェックインしたいと思うときはいつでも、それを避ける方法を考えてください。私の経験では、ほとんどの場合、データの不一致、ソースの欠落（たとえば、圧縮されたDDSテクスチャがチェックインされますが、ソースpngはチェックインされません）、および混乱が発生します。エクスポートされたファイルがどこかにキャッシュされることでより適切にアセットパイプラインが提供される場合（だれもが同じファイルセットを再生成しないため）、VCSでソースアセットを構築し、エクスポートされたファイルをキャッシュ（または共有ドライブ、または別のVCS）。ただし、これらのエクスポートされたファイルを手でチェックしないでください-特にチームの一員として作業している場合は、噛みつきます。

私はその本が大好きで、関連する関心を持つすべての人にお勧めします。一人の男性のインディーズプロジェクトの場合、別のバージョンを作成する必要がある場合や作成する場合を除き、実際に分岐する必要はありません。1つはAndroid用、もう1つはPC用、またはそれらに沿ったものです。

あなたが言ったように、あなたが良い習慣を取りたいなら、私はマイクのアプローチで行くでしょう。それは非常に理にかなっており、私が2人のインディーズプロジェクトで使用しているアプローチです。

戻って作業を進めるために必要なものはすべて、 進めるために必要なすべて分岐ます（ただし、必ずしも分岐している必要はありません...まだ）。

その理由は簡単です。他のコードではなく、そのコードの修正バージョンを発行できる必要があるため、その時点でブランチで作業する必要があります。

VCSは異なります。gitなどの一部は、後でコミットから簡単に分岐できますが、CVSなどは、後で作業するのが非常に面倒です。

おそらく、選択したバージョン管理システムで最適に動作する方法を尋ねて、stackoverflowに関する質問を開きたいですか？あなたがいない場合は、本当に歴史の多くのまだ開始、あなたは仕事のやり方を記述し、質問を開いて、あなたのための最良のバージョン管理システムの推薦をお願いしたいことがあり？