Backing Up Your Projects: A Beginner's Guide
Updated a year ago
4.7 K

One question I’ve seen quite a bit is how to either backup a project or transfer it to another machine. In some painful cases, people have even asked how to recover lost or corrupted projects only to realize not much can be done.
There are a few ways you can store your project on the cloud via version control, including Unity’s built in method with Unity Collaborate. However, we’re going to be going through the basics of how to use Bitbucket and Sourcetree to keep everything nice and safe.
In summary, this will cover:
  1. How to set-up a repository on Bitbucket
  2. How to clone (make a local copy of) the repository through Sourcetree
  3. How to push (backup) changes
  4. How to pull (download) new changes
This article is specifically written to guide beginners into the world of version control and will only cover the basics. However, this is more than enough to keep your project safe and accessible.

Creating a Repository

A repository is online storage where your project will exist. There are various services that provide free repositories, but we’ll be using Bitbucket. Begin by visiting the site and choosing to Create an Account.
Once signed in, you will see your Dashboard. Here you will see a list of all your repositories though at the moment it will be empty. Creating a new repository is simple:
  1. Select the [+] sign and create Repository.
  2. Name your first repository, leaving everything as default for now such as keeping it private and setting the version control system to Git.
You will be redirected to the repository page, which is now also accessible from your dashboard. The two most important views are:
Source which will contain a list of all your project files. Right now we haven’t uploaded your project, so it will contain some tutorial text.
Commits which will show you a history of all the changes you’ve made. This is very important should you ever need to look up what you changed or revert your project to a previous commit.

Cloning a Repository

Like creating a repository there are different programs you can use to access them. In this tutorial we’ll be using Sourcetree. Simply download and follow the instructions leaving everything as default.
Once downloaded, we can create a local copy of the repository on our machine:
  1. Link your Bitbucket account to Sourcetree by selecting the Remote tab followed by Add An Account.
  2. In the pop-up window, make sure the hosting server is set to Bitbucket. Select the Refresh OAuth Token which will open a browser to verify your login.
  3. Once the account is authenticated you will see your repository listed in the Remote tab.
Now that you’ve gained access to your repositories, we can now begin to clone and backup the project:
  1. Select the repository from the list then click Clone.
  2. This will redirect you to the Clone tab with auto populated fields.
  3. Change the location by selecting the second Browse option. If you want to create a new folder, simply append it to the end of the download location.
  4. Click Clone to download the repository. This will create the new folder (if you made a new one) or link the repository to an existing folder you’ve pointed to.

Backing Up Changes

There are three terms we need to be familiar with when backing up repositories:
Staging is selecting files to commit as you decided which changes you want to send to the repository
Committing is preparing the backup
Pushing is sending the commit to the repository
We will make our first push to the repository, but before sending the project, we will first push something called a Git Ignore file. This is important to do as a first step before adding any Unity project files. What this ignore file does is notify Sourcetree which files to skip when looking for changes which will reduce the size of the repository, and more importantly, make it a lot easier to manage.
Fortunately, the community has created a ready made git ignore file for Unity:
  1. Browse to this link to get the git ignore file.
  2. Copy the contents into a text file. You can name it whatever you like but the file extension must be .gitignore.
  3. Move the newly created text file into your repository folder.
Since we’ve made a change to the local version of our repository, in this case adding a new file, Sourcetree will recognize the change as long as the file type is not listed in the git ignore.
Let’s make our first commit and push it to the repository:
  1. In the File Status tab you will notice the git ignore file is displayed in the Unstaged Files section.
  2. You can selectively choose which files to send to the repository by selecting them and clicking Stage Selected. Alternatively, if you want to push all the changes, simply choose Stage All. Notice how your staged files move to the Staged Files section; essentially the holding grounds before a commit is made.
  3. At this point, you will want to write a description for your commit in the box below. The more descriptive, the better, as you will be able to use these messages should you ever need to check what past changes were made.
  4. Once you have decided on your message, click the Commit button.
Now that your commit has been finalized all that’s left to do is push it to the repo. You might have noticed that the Push button in Sourcetree now has a [1] on it, indicating that there is one commit that is waiting to be pushed. Note that you can create as many commits as you want before sending them to the repository:
  1. Click the Push button.
  2. Check the box beside master if not already marked. For now, all you need to know is that this is the main repository you have on Bitbucket.
  3. Click the Push button and wait for it to complete.
If you visit your repository on Bitbucket you will see that the source now lists your git ignore file and the commits will display the pushes with their their messages (this is why it’s important to have something descriptive).
At this point you can now back up your project. Copy your project files into your local repository folder and following the steps you have just learned: stage the changes, create a commit and push it to your repository.

Retrieving Changes

When changes are pushed to the repository, any machine that has a connection to it will be able to download those updates. There are two terms to know here:
Fetching is checking if there are any new changes made to the repository, such as a coworker who had recently pushed a change.
Pulling is downloading those updates to your local repository.
To download the changes:
  1. Click the Fetch button, leaving everything as default in the pop-up.
  2. If there are updates to be downloaded, a number will appear on the Pull button.
  3. Click the Pull button, leaving everything as default in the pop-up.
Your local folder will now update with the changes to match what’s on the master repository.

That’s all there is to it!
Over time as you repeat these steps, it will become pretty natural. There are plenty of other things we can dive into such as branching, merging and conflicts, so if requested we could look at those in another article. In the meantime, this should definitely be more than enough to help ensure your projects are safe from being lost.
Thanks for reading and hopefully version control doesn’t seem so scary any more.

We’ll end the article with a list of additional pointers to keep in mind:
  1. Always make sure to check for any updates before starting work, in order to avoid conflicts.
  2. The Log / History tab in Sourcetree will show you all the previous commits. Here you can revert to previous versions.
  3. Files which are non-binary (such as scripts) can merge and combine changes whereas binary (such as scene files, models, etc) cannot.
  4. Although we connected to the repository via the Remote tab, you can clone any public repository directly in the Clone tab and pasting the link into the Source URL.

Other Projects
Matthew Ostil
Game Designer & Developer - Programmer
Luigi Lescarini
a year ago
Founder of Infinity Mundi + Full Stack Dev
@Matthew Ostil thanks for the article! Can you compare this versioning pattern to Unity Collaborate? Can they co-exist?
Please discuss about branching, merging, resolving conflicts, and any advanced topic on version control for the next article.
Matthew Ostil
a year ago
Game Designer & Developer
Maciej MiąsikI believe that this sentence: "Files which are binary (such as scripts) can merge and combine changes whereas however non-binary (such as scene files, models, etc) cannot." should be the other way around.
Thanks for the correction!
Maciej Miąsik
a year ago
I believe that this sentence: "Files which are binary (such as scripts) can merge and combine changes whereas however non-binary (such as scene files, models, etc) cannot." should be the other way around.