What’s a Remote?
So far, everything we’ve done is on your local computer.
We haven’t added any remote servers, and if your computer gets stolen, hdd dies, or some other disaster, you’ll wish your project was backed up somewhere else.
Adding a remote server also allows you collaborate with others, but even if you don’t plan to do that, the benefits for yourself are more than worthwhile.
Adding a Remote
First, you’ll need to create an account on one of the big remote git hosting sites.
You’re welcome to use whichever you like. I use BitBucket so I’ll guide you through setting one up on there.
Create an account on https://bitbucket.org or log into your existing one. (Sourcetree and BitBucket use the same credentials)
Once you’re logged in, you’ll be at your “Dashboard”
From there, click the repositories menu, then “Create Repository”.
Give the repository a proper name and click “Create repository”.
Once the repository is created, you’ll be redirected to the project “overview” page.
On there, you’ll see a URL that looks something like this, but with your username.
Select the text and copy it. This has the full URI for your repository remote.
For example, mine is: https://jasonweimann@bitbucket.org/jasonweimann/git-branching.git
Back to SourceTree
Now that you have your remote URI, switch back to sourcetree then select Repository->Repository Settings…
Click the “Add” button to add a remote.
Check the “Default Remote” box.
Paste your URI from the clipboard into the “URL / Path” field.
Click OK.
When you’re prompted to log in, use the same credentials you used for the bitbucket account.
Pushing to the Remote
Now it’s time to push.
The Push command tells GIT to send your current branch to the remote repository.
Click the “Push” button.
Click the checkbox for “master”, then click OK.
You’ll see the progress bar for a second or two.
If all goes well, you’ll be back in your “master” branch view.
Take note of 2 new things though.
On the left, under “Remotes” we now have “origin”.
And in the commit history, we can see that the “origin/master” branch is set to the same commit as our local “master” branch.
This means that our branches match, which we’d expect since we just pushed our master branch to the remote “origin”.
Pulling from Remotes
Pushing your work to a remote server is great, but if you don’t know how to pull from the server there’s no value.
Of course like most things in GIT, it’s not too hard of a process, but there are some intricacies that are important to understand.
To try this out, let’s clone the repository into a new folder, from the remote.
Click the “Clone / New” button.
You’ll be presented with a dialog to enter your Source URL & Destination path.
Paste the source path into the URL that you used for the remote origin.
For the destination path, make sure the directory is DIFFERENT from the directory you’re working in. In my screenshot, you can see I’ve placed it into a folder named “gitpull”.
Click the button.
Wait for the clone progress window to finish.
When it finishes, you’ll be greeted with something that looks very familiar.
Why does this look exactly the same?
What we’ve done here is take our remote repository and clone it to our local system in a brand new folder.
This is the same process that another person would follow to clone your repository and work with you.
I want to be clear though that we’re doing this for learning purposes only, there’s no good reason I can think of for you to clone your own repositories in more than one place on a system.
If you want to work on a desktop and a laptop though, or some other multi computer setup, this is exactly the process you’d follow (though you could have the same local directory / Destination Path since they’d be on different computers).
Let’s Push and Pull again!
Switch to the Git Branching repository by clicking on the tab.
All of your recently opened repositories show up as tabs in sourcetree. If you don’t see the one you want, they’re also bookmarked on the left. Double click the one on the left to open it as a tab.
Select the master branch. It should look like this.
Back to Unity
Let’s jump back over to Unity now.
Right click on the TallBox and create a new Cube as a child.
Adjust the transform values so it looks something like this.
Apply the prefab.
Save the project.
Before we go back to GIT
Let’s open another instance of Unity.
Open the project located in the folder you did the pull to.
Mine was c:\git\gitpull.
It should look just like your project did before we edited the prefab.
Back to SourceTree!
Okay it’s time to commit, push, and pull.
If your working copy looks like this, go back to Unity and make sure you saved.
Hit the Stage All button.
Notice that in my unstaged files, I had the TestScene, but when I hit Stage All, I only have the prefab.
This is because the Scene isn’t actually changed. The timestamp on it updated when I saved it earlier so it showed up in the Unstaged area.
But the contents didn’t change at all since we only modified the prefab, so when we go to stage, it does a comparison and realizes it doesn’t need to be committed.
Enter a commit message “Added top to the TallBox” and click commit.
Now push the commit to your remote.
You’ll see a dialog like this again, click Push.
Now select the tab of your gitpull repository.
Nothing changed??
It probably looks the same, that’s just because it hasn’t refreshed.
Click the Fetch button to get a refreshed view of the repository and it’s remotes.
You’ll get this dialog, leave the default and just click ‘OK’.
It’s changed! The remote is ahead
Now when you look at your master branch, you’ll see something that could be confusing. I know it confused me at first…
What this image is conveying is that the “origin/master” branch on the remote is ahead of my local “master” branch.
The local master branch even says on it that it’s “1 behind”, meaning there’s 1 commit on the remote that we don’t have locally.
Don’t Pull yet
We could hit pull and get our local master up to the same commit as the remote, but before we do that, let’s reproduce a VERY common issue that people get caught up on every day.
This needs to be done in the other instance of Unity not the primary one, need to update this and talk about opening the other instance.
Go back to Unity
Make sure you’re in the the ‘gitpull’ project
To make things easier, I’d recommend opening both project in separate Unity instances if you can. If you’re resource limited though, you can just open the projects as needed.
Open the TestScene.
In the Project View, create a new folder and name it “Materials”.
In the Materials folder, create a new material, then name it “Blue”
Select the “Blue” material and change the color in the inspector.
Assign the blue material to the tallbox prefab.
Click Apply to update the prefab
Save your project
Save the scene.
Back to SourceTree
In the ‘gitpull’ repository, click pull.
Click ‘OK’
An ERROR!
You should have received this error message.
It’s telling you that you can’t pull because you have local changes that would be overwritten if you did.
Let’s look at those local changes.
Go to your “Working Copy”
Here, you’ll see we do have changes, and since TallBox.prefab was modified in the most recent commit, it definitely would conflict.
Let’s see how to resolve that!
Stage your changes.
Commit your changes in the working copy.
Switch back to the “master” branch view.
Pull again
Success!!!
But what’s this?? “Uncommitted changes”??
What’s happened here is GIT has automatically created a merge for you. It knows that there were changes to the TallBox.prefab file from a remote, and that you had changes to it locally.
Now it’s up to you to decide how to resolve it.
Go back to the “Working Copy”
Great, in this instance there’s no conflict! We’ve done a successful merge, and because the properties we changed were different, everything worked automatically!
It’s worth noting that often you’ll run into a conflict. In that case, it’s up to you to decide which version to take. In some instances, you can combine the changes and get something that works, but with prefabs, if there’s a conflict, it’s often more difficult to work around a conflict than to just re-create the change.
Click Commit
Go back to Unity
Check out the merged prefab!
Notes
This guide has taken you through a lot, and if you aren’t really comfortable with this process yet, try repeating it 2 or 3 times. By then, if I haven’t totally messed this up, it should be a bit more apparent how things are merged, how remotes work, and how you can get some real value out of git.
Again, I’d really recommend you practice with this simple project before trying to do it on your real projects. Here, if something goes wrong, you just start right over, in a real project, if you mess up, there’s the possibility you waste hours trying to fix stuff 🙂
If there’s demand for more on GIT, I’ll continue on with this series. There are still plenty of topics to cover… branching, more in-depth merging, stashing, etc…
If you’d like more GIT tutorials, just drop a comment and let me know.
Thanks!