このトピックでは、Stingray ソース コードのリポジトリについて説明し、これらを使用するための推奨ワークフローをいくつか示します。
「Stingray 開発者として登録する」に記載されているすべての手順に従った場合は、GitHub で Autodesk Games チームのメンバーになるよう招待されているはずです。
次の URL にあるチームのホーム ページにアクセスしてください。
https://github.com/AutodeskGames
stingray という非公開のリポジトリを確認してください。このリポジトリは、Stingray ソース コードを使用する場合の主な出発点となります。このリポジトリには、エンジン、エディタ、およびその他の Stingray 編集ツールの完全動作バージョンを再ビルドする際に必要となるあらゆるものが含まれています。ソースにアクセス可能なすべてのお客様は、このリポジトリを開始点として使用してください。
公式リリースとして出荷される Stingray のバイナリ バージョンには、表示したり使用したりする場合に特殊なアクセス権が必要となる追加コード モジュールもいくつか含まれています。これらのモジュールは、GitHub のメイン Stingray リポジトリにサブモジュールとしてリンクされている、独自のリポジトリに隔離されています。
お客様の組織がこれらのモジュールの 1 つまたは複数のコードにアクセスできる場合は、Autodesk Games チームの下に追加のリポジトリが表示されます。
stingray-ps4: PlayStation 4 コンソールで使用するコードです。Sony の許可に基づき、オートデスクは PlayStation のライセンスを所有する開発者にのみこのコードを配布します。
stingray-xb1: Xbox One コンソールで使用するコードです。Microsoft の許可に基づき、オートデスクは Xbox のライセンスを所有する開発者にのみこのコードを配布します。
stingray-internal: 公式リリース用のオートデスク関連の内部コードです。ライセンス管理、クラッシュ報告、オートデスク ユーザ アカウントの管理といった、お客様のカスタム ビルドには関連していません。このモジュールはお客様にリリースされません。
オートデスクでは、このコードの Git サブモジュールを使用することにより、モジュールの相互同期を常に維持したままアクセスをコントロールするよう試みています。ただし、この試みが実現すると、リポジトリのクローンを作成して操作する場合の複雑さが増します。ゲームの前に少し時間をかけて、Git サブモジュールの仕組みについて理解することをお勧めします。
基本的に、各モジュールは別のリポジトリからの特定のコミットを示すポインタにすぎません。stingray リポジトリには、上記の各モジュールにそれぞれ対応する、これらのサブモジュールのポインタが 3 つ含まれています。サブモジュールのクローンを作成すると、この指定したコミットにおけるコードのクローンがリポジトリから作成され、メインの Stingray リポジトリのローカル クローンに格納されます。各サブモジュールは「ネストされた」リポジトリとみなすこともできます。
サブモジュールのその他の背景情報については、Git のドキュメントまたは GitHub ブログを参照してください。
これらの Stingray サブモジュールを使用するためのリポジトリを実際に設定する手順については、「ソースのクローンを作成してサブモジュールを管理する」も参照してください。
すべての Stingray リポジトリには、既に次のブランチが設定されています。
master: テスト済みの QA で承認されたブランチです。通常は、公開リリースされたバイナリ インストーラ パッケージのマイルストーン リリースに対応しています。ここには、前回の更新以降に develop ブランチで行われたすべての変更をロール アップする、コントロール済みのアップデートが定期的に配信されます。
develop: オートデスク内部で使用される社内開発用ブランチのライブ ミラーです。このブランチには、破壊をもたらす可能性のあるコミット事項が頻繁に配信されます。したがって、master ブランチに対する前回の更新以降に導入された特定の機能または修正プログラムが必要な場合を除き、master ブランチから作業することを一般にお勧めします。
develop ブランチで作業する場合は、最新コードに更新するたびに、ゲーム プロジェクトおよびアセットをバックアップすることをお勧めします。これは、develop ブランチが不安定であるためにデータが破壊された場合に、回復するのに役立ちます。
release/1.X.0: これらのブランチは、連続する各公開リリースの準備状況に応じて表示または非表示になります。リリース ブランチが開いている場合、このブランチは一般に既存機能についてのバグ修正のみを受信します。新しい機能は通常、develop に送られ、後続の公開リリースに組み込まれます。
Web 上のこのドキュメントの内容の大部分には、master ブランチの現在の状態が反映されています。develop ブランチを操作する場合は、リポジトリのルートにある readme.md ファイルに目を通して、必要なソフトウェアの更新およびビルド プロセスを確認してください。
アクセス可能な Stingray リポジトリごとに独自の分岐を作成することを強くお勧めします。
独自のバージョン管理システムで Stingray ソースを操作する場合は、Autodesk Games ブランチのクローンを直接作成するか、あるいはコードベースの zip をダウンロードする方法の方が、簡単で、時間がかからない可能性があります。ただし、独自の分岐を使用する方法には、いくつかの利点があります。
トレーサビリティが向上します。最後に取得したブランチおよびバージョンの明確な記録が常に残り、独自のコード ベースの開始点とオートデスクで共有されているいずれかのブランチの任意のバージョン、またはコミュニティ内の別のユーザが共有している任意のブランチとの差分を簡単に作成できます。
結合が容易です(容易になる可能性があります)。コード ベースを更新してオートデスクから新しい変更を取得する必要がある場合(「オートデスクの最新の変更内容に更新する」を参照)、Git は可能な限り合成を自動実行し、ユーザが自分のブランチに行った可能性のあるカスタム修正と競合する更新があれば、ユーザに警告します。
変更を投稿するのが容易です。メインの Autodesk Games リポジトリ内で変更を直接合成したり、ブランチを作成したりすることはできません。したがって、独自の修正または新しい開発内容のいずれかを Stingray コミュニティに投稿する場合は(「Stingray コミュニティへ変更内容を投稿する」を参照)、プル リクエストの送信元となる独自の分岐が必要です。
独自の分岐が作成されたら、ソース コードのローカル コピーのクローンを作成して、操作するコンピュータに保存することができます。
独自の分岐を作成する場合は、これらの分岐にアクセスできるユーザを把握する必要があります。
オートデスクの管理者は、お客様の分岐に対するフル アクセス権を常に持っています。 つまり、オートデスクはお客様がプッシュしたすべての変更を参照したり、お客様のリポジトリの設定を修正したりできます。
このアクセス権は取り消すことができません。このようになっている原因は、GitHub の非公開リポジトリ共有モデルにあります。
既定では、お客様の分岐に対して、Stingray ソースの他のすべてのお客様が読み取りアクセス権を持っています。 つまり、他の組織の開発者がお客様の分岐にプッシュされたすべての変更を見ることができます。
分岐の設定で、このアクセス権を取り消すことができます。GitHub のお客様の分岐野ホームページで Settings をクリックします。Collaborators タブにリストされた、除去可能なすべてのチームを除去します。
Autodesk Games リポジトリから行った分岐に対する変更をプッシュする場合は、その変更をオートデスクが表示できるようになっていること、および組織外のユーザが表示できる可能性があることに注意する必要があります。したがって、Stingray コミュニティに送信し直す変更、または機密事項や知的財産権が含まれていない変更のみを送信することをお勧めします。
組織内にソース コードのバージョン管理システムが既に配置されていて、使い続けたいことがあります。オートデスクから Stingray コードのリビジョンを取得した後に、stingray リポジトリの分岐内で日常的な開発を継続するための要件はありません。このコードを独自のバージョン管理システム内に配置し、独自のツール セットを使用して、新しいリビジョンを既存のコード ベースに合成することができます。
この設定で使用する GitHub の役割は、オートデスクの変更内容を選択して、変更点をオートデスクに投稿するためのメカニズムに限定されています。
ただし、このコードへのアクセスを保護するのはユーザの役割です。Stingray ソースを独自の公開リポジトリ内や、ライセンスを持たない組織外のユーザがアクセスできる場所に配置しないでください。