Source code management

This topic describes the Stingray source code repositories, and provides some recommended workflows for consuming them.

About the repositories

If you have followed all the steps described under Register as a Stingray developer, you should have been invited to become a member of the Autodesk Games team on GitHub.

Visit the team's home page at:

https://github.com/AutodeskGames

You should see a private repository named stingray. This repository is your main entry point to the Stingray source code. It contains everything you need to rebuild fully working versions of the engine, the editor, and the other Stingray editing tools. All customers with source access use this repo as a starting point.

About the submodules

The binary versions of Stingray that we ship as official releases also contain some additional code modules that require special access rights to see and use. These modules are isolated in their own repositories, which are linked in to the main Stingray repository on GitHub as submodules.

If your organization has access to the code for one or more of these modules, you should see additional repositories under the Autodesk Games team:

By using Git submodules for this code, we are trying to control access while enforcing that the modules always remain synchronized with each other. However, this does add some complexity to cloning and working with the repository. We recommend that you invest a little time up front in gaining a good understanding of how Git submodules work.

Essentially, each submodule is a just a pointer to a specific commit from a different repository. The stingray repo has three of these submodule pointers: one for each of the modules listed above. When you clone a submodule, the code at that specified commit is cloned from its repository into your local clone of the main Stingray repo. So, you could also think of each submodule as a "nested" repository.

For more background information on submodules, see the Git documentation or the GitHub blog.

For practical instructions on setting up your repo to use these Stingray submodules, see also Clone the source and manage submodules.

Branch conventions

All Stingray repositories are already set up with the following branches:

For the most part, the contents of this documentation on the web reflect the current state of the master branch. If you do choose to work with the develop branch, keep an eye on the readme.md file at the root of the repository for any updates to the required software and build processes.

Forking the repositories

We highly recommend that you create your own fork of each Stingray repository that you have access to.

If you intend to work on the Stingray source in your own version control system, it may seem simpler and faster to clone the Autodesk Games branches directly, or even download zips of the codebase. However, using your own forks has some advantages:

Once you have your own fork, you can clone a local copy of the source code to your computer to work with.

Access to private forks

If you create your own forks, you must understand who has access to those forks:

You must be aware when you push changes to a fork that you have made from the Autodesk Games repository that you are making it visible to Autodesk, and potentially to others outside your organization. We therefore recommend that you only push changes that you intend to submit back to the Stingray community, or that does not contain any sensitive material or intellectual property.

Working with your own source control system

You probably have a source code versioning system in place within your organization already, which you may want to continue using. Once you have retrieved a revision of the Stingray code from Autodesk, there is no requirement to continue doing day-to-day development in your fork of the stingray repo. You can put that code into your own version control system, using your own set of tools for merging the new revision into your existing code base.

In this setup, you'll use GitHub only as a mechanism for picking up changes from Autodesk, and potentially for contributing changes back to us.

However, remember that you are responsible for protecting access to this code. Please do not put the Stingray source into your own public repositories, or anywhere else that is accessible to unlicensed users outside of your organization.