Defold is built intended for small teams that work in intense collaboration to create games. Team members can work in parallel on the same content with very little friction. Defold has built in support for version control using Git. Git is designed for distributed collaborative work and it is an extremely powerful tool that allows for a wide range of workflows.
When you save changes in your local working copy, Defold tracks all changes in the Changed Files editor pane, listing each file that has either been added, deleted or modified.
Select a file in the list and click Diff to view the changes that you have done to the file or Revert to undo all changes and restore the file to the state it had after the last synchronization.
Project synchronization is only available for projects hosted on the Defold Dashboard. Projects hosted on GitHub or in other Git repositories will not be able to use synchronization. There are however many excellent external tools for working with Git repositories with GitHub Desktop, GitTower, Git Kraken and SourceTree being some of the more popular ones.
To synchronize your project means that the project files are brought into sync with the project as it looks on the server. You should synchronize if:
To start synchronizing, select File ▸ Synchronize in the menu. A series of dialogs guide you through the synchronization process.
Press Pull to pull changes from the server and merge them with your local changes. If there are conflicts, you are asked to resolve them:
Mark each conflicting file, right-click and select the action to take:
Bring up a textual diff view of your and the server version of the file.
On the left hand side is the file pulled from the server. The right hand side shows your local version. Any differences are clearly highlighted so you can quickly review them.
The built in file comparison tool works on text files only. However, since Defold stores all working files (game objects, collections, atlases, etc etc) in easily understandable JSON files, you can often figure out the meaning of the changes that have been made to such files:
Discard the changes from the server and instead use your version.
Discard your version and instead use the server version.
The editor does not allow you to pick changes from the two conflicting files. If you need to do this you can perform the Git operations from the command line and use a separate merge tool.
When the editor is done pulling changes and any conflicts are resolved, a dialog asks you how to proceed.
If you continue pushing and have local changes, you are asked to commit them before pushing. A dialog allows you to select (stage) the files that should be included in the commit framed orange in the image below).
Press Push to commit and push your changes to the server.
Git is built primarily to handle source code and text files and stores those types of files with a very low footprint. Only the changes between each version are stored, which means that you can keep an extensive history of changes to all your project files to a relatively small cost. Binary files such as image or sound files, however, does not benefit from Git’s storage scheme. Each new version you check in and synchronize takes about the same space. That is usually not a major issue with final project assets (JPEG or PNG images, OGG sound files etc) but it can quickly become an issue with working project files (PSD files, Protools projects etc). These types of files often grow very large since you usually work in much higher resolution than the target assets. It is generally considered best to avoid putting large working files under the control of Git and instead use a separate storage and backup solution for those.
There are many ways you can use Git in a team workflow. The one Defold uses is as follows. When you synchronize, the following happens:
If you prefer a different workflow you can run Git from command line or through a third party application to perform pulls, pushes, commits and merges, working on several branches and so on.