This post is the first in a series of articles covering GIT for Unity Developers.  GIT is a great tool for any developer, but if you’re new to it, there are quite a few concepts to cover, and I’ve found most tutorials only cover a small part. This series will focus on what’s needed to make good use of GIT with as little complication and confusion as possible.  While I know many developers love using the GIT CLI, I find it to be far from user friendly, and frankly a bit of a distraction for anyone who just wants to get work done.  So we won’t cover that, but we will cover the features and concepts I find most teams using day to day.  By the end of the series, you’ll be a Unity3D GIT pro!

Prerequisites

To follow along, you’ll need Unity and SourceTree installed.  Any version of Unity should work fine, I’m doing this in 5.5.

Unity – You should know what this is if you’re reading this.

SourceTree – A free visual Git client for Mac and Windows

 

Project Setup

First, we’ll create a new project and name it “Git Branching”.

Browse to the folder where we’ll create a new file named “.gitignore”.  (The filename is blank with only an extension of gitignore)

Edit the .gitignore file with your favorite text editor (I use Notepad++ for these things).

Paste in this gist.

Git Setup

Open SourceTree.

Click on the Clone / New button.

Select the Create New Repository tab.

Enter the destination path that matches your folder structure.  Mine is located in “c:\git\Git Branching”

Click Create

First Commit

The git repository will be created and you should see this.

If you see a bunch of files in the Library folder, your .gitignore file isn’t correct.  Go back and double check that you have it named right and in the correct location.

Click the “Unstaged Files” checkbox to move everything into the Staged files area.

At the bottom of the screen you’ll see the Commit message area.

Type in “Project Settings and .gitignore”, then click the commit button

.

Once the commit completes, switch from viewing the “Working Copy” to viewing the “master branch” by clicking on “master”.

Here, you’ll see our first commit, with the commit message we entered.

I often see people write short commits with no information about what changed.  While it will save you a couple seconds at commit time by not having to think about what you’re committing, it will generally take a lot more time for you to try to figure out when someone commited some broken change.  Commit messages also serve to inform the rest of your team about what you’re doing (or remind you when you try to remember where you left off)

Serialization

When you use GIT as a source control engine, it’s recommended to use the Text serialization mode in Unity.  This is helpful when you need to merge later.

Open the Editor Settings page.

In the inspector, select “Force Text” for the serialization mode.

Now go back to SourceTree.

Switch back to the “Working Copy” view b y clicking on “Working Copy”.

Stage all the changed files by clicking the “Unstaged files” checkbox.

Enter a commit message that says “Changed asset serialization mode to force text”.

Click Commit.

If you look at the “master” branch again, you should see two commits now.

Let’s do some work (in Unity)

Okay, you’ve commited 2 things already, but haven’t done anything in the engine yet.

Let’s change that now.

Creating the TallBox

In Unity, create a cube

Name it “TallBox”.

Set the scale to (1, 2, 1) .

Making the Prefab

Create a folder for prefabs.

Drag the “TallBox” into the prefabs folder to make it into a prefab.

Save the Scene

Save your scene in a folder named “Scenes” and name it “TestScene”.

Commiting the Prefab

Switch back to SourceTree.

In your “Working Copy” you should see 6 changed files.

Select the 3 that are related to the TallBox prefab.  You can batch select them and hit space or check them individually.

Your “Staged files” area should now contain the 3 TallBox related changes while your “Unstaged files” area still has the Scene changes.

Type in the commit message “Created TallBox prefab”, then click commit.

Why didn’t we do the other files?

The reason we only commited the prefab and not the scene is to keep our changes logically grouped.  Since the scene change isn’t directly related to the prefab it’s good to let it have it’s own commit.  For this example it may seem like overkill, but as your project grows, you’ll want to be able to occasionally undo a commit.  The less that’s in each commit, the easier it is to deal with them.  There are of course limits, but a general rule of thumb is to group all of the files for a single change or feature into a commit.

Commit the Scene

Select 3 the scene related files and commit them.

Your master branch should now contain 4 commits.

Checking Out

Before we move to more advanced things like branching, let’s cover what the checkout command does.

In the “master” branch, right click on the first commit “Project settings and .gitignore”, then select checkout.

You’ll be presented with a confirmation dialog that talks about your detached HEAD.  Don’t worry about it, check the “Clean” box and hit OK.

Go back to Unity and you’ll see that everything is gone.  That’s because we’ve checked out a commit from before the prefab was created or the scene was saved.

Not worry though, our changes are in GIT.

To get back to them, select the most recent commit “Created Test Scene”, right click, and Checkout.

Go ahead and try this with the different commits and check Unity, you’ll see that you can get back to any state.

With GIT, you have fast, clean, bookmarked history.  And that’s just the start.