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.

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

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!

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!

You should be using GIT

If you’ve been using source control, but haven’t made the change to git yet, let me try to convince you.  I first heard about git a few years ago.  It sounded interesting at the time, but my source control was working fine (or so I thought), so I didn’t pay too much attention.  Around 4yrs ago, I started a new project and had to pick a source control system.  One of the options we tried out was git.  Like most people, I searched google, read a bit of the docs, then hopped into the command line.  It was a disaster….

I’ve used command lines since the C64 days, can easily handle dos, powershell, and USED to be good with with linux.  That said, I’ve been primarily developing on windows, building games, websites and apps since the 90’s.  Using git via the command line felt un-intuitive and confusing.  Combining that with a new set of definitions for commands made it more confusing.  All this combined into the perfect storm of confusion.

Around 2 years ago I attended a few “Intro to Git” talks that explained the basics.  They always covered how git works and how to get around the command line.  They’d occasionally touch on the fact that visual tools existed, but they’d  focus on the command line because people who love git enough to do talks on it, love command lines.

The first thing I want to say if you’ve been avoiding git because it seems complicated/confusing, ignore the command line.  You can learn to use it later.  For now, grab one of the good graphical tools and get a bit of experience with git.  My preferred git tool is SourceTree.

Graphical tools have existed for every other source control system, so you may still need some more convincing.  The typical git pitch mentions things like offline commits & easy branching.  I won’t be covering those today.  Instead, I’ll focus on 4 points where git excels which I think may be more convincing.

#1. No file locking / read-only files

This may not be an issue for everyone, but if you’ve been a long time perforce user then you’ve fought with read-only files.  If you also happen to use Unity3D, you’ve realized just how terrible it can be.  With git, your files will no-longer be locked, read-only, or need to be checked out before you can work.

#2. Partial file commits

This one alone may be enough to convert some people.  Before switching to git, I can’t count the # of times where I was working on a feature, but needed to make a quick minor fix.  Before git, I’d stash my changes to the file in question, make the fix, and hope everything still built.  Then I’d commit, un-stash, and hope I didn’t mess up my previous work.

Git offers the perfect solution to this.  Partial commits.  If you’re using source tree, you can see just how easy it is in the image below.  It will find the different areas of your file that have changed, and you just choose the part(s) you want to stage for commit.  You can simply commit what you want, and leave out everything else you’ve been working on.

 

#3. Commit changes without pushing them

You can commit, without pushing out your changes to anyone else.  If you’re still working on a feature, not sure about your code, or you’re just afraid to break an upcoming release, you can still commit.  Until you PUSH, your code is only committed locally.  You can roll back your changes, modify them, etc, without anyone else having access to the code until you’re ready.   It’s liberating…

#4. Finding changes is EASY

I can’t speak for all version control systems, but in many, finding your changes can be a pain.  Some systems like P4 require you or a plugin to specify each file (there are ways to find them, but they’re a pain too).  With git, it looks at the file system and sees your changes every time.  In the graphical tools, you get a nice easy view of all your changed files where you can choose which ones (or parts) to stage for commit.

There are of course many other reasons to use git.  It’s taken over as the primary source control system because it’s better than the competition.  I’m happy to have made the switch, and can’t imagine ever going back.  I hope I’ve convinced you as well.