Game Dev Journey: Repo Man

Mike Bischoff
6 min readMar 30, 2021
Logo courtesy github.com

Even as a solo dev, good version control habits are extremely important to develop. Keeping a running log of project changes stored remotely on a server means no matter what, you’re a few keystrokes away from recovering days, weeks, months of work should disaster strike. Or you can test out new features and functionality by branching out your project into parallel versions, safe in the knowledge that you have your main project trunk intact.

Once you start working in teams, versioning will need to become second nature as each of you will be working on separate aspects of the same project.

This quick start guide will get you started connecting your Unity projects to Github via the Git Bash console interface. It’s not an exhaustive guide on the subject, but by the end you should be comfortable pulling from the server, committing your changes and pushing them back to your main branch.

Note that I’ll be employing some newer terminology in the Git Bash environment, namely using “main” instead of “master” and the “switch” command instead of “checkout.”

Creating Your Repository

I’m going to assume you have a GitHub account or know how to set one up, so we’ll start by creating a new repository by clicking the “New” button in the upper left-hand corner of the homepage.

You should also switch to dark mode, obviously

On the next page, you’ll choose a name for your new repository, decide if it will be public or private and choose whether to include a ReadMe, a .gitignore template or a usage license.

Pretty straightforward, ain’a?

The .gitignore template will block unnecessary project files from being passed back and forth each time you push or pull a commit. You can edit this file if there are any changes you want to make to the defaults.

Licenses, such as the GNU General Public License, instruct what other users are or are not allowed to do with your code. No license means any public repo can be used however an outside user sees fit. If you do choose a license, be sure to familiarize yourself with its terms.

Click “Create repository” to go to the next step.

Connecting Git Bash to Your Repo

There is a GUI version of Git Bash, but we’ll be using the command line, because we’re hard like that. It’s actually pretty easy to pick up once you get used to the main commands you’ll be using:

  • cd — Changes the directory you’re in
  • ls — Lists folders inside your current directory
  • git init — Initializes git in the current directory
  • git pull — Pulls most recent commit in your active branch from the server
  • git commit — Commits your work in preparation to upload
  • git push — Uploads your commited branch to the server
  • git status — Displays files that still need to be added before committing
  • git add — Followed by a specific file name, or a period to add all files
  • git branch — Used to display all branches and to create new ones
  • git switch — Switches between branches (git checkout also works)
  • git merge — Merges one branch into another

Inside Git Bash, use ls and cd to navigate to your project directory. Alternatively, you can open the directory in Windows Explorer, right-click and select “Git Bash Here.” Your relative location will be displayed in yellow next to your name in the console window.

Next, enter the command git init.

Git initialized inside the project directory

At this point, we need to tell Git Bash where our server is. Inside your GitHub repository, click the “Code” dropdown button and copy the URL.

As you can see, there are several other options for code cloning for you to explore and experiment with

The next command we enter is git remote, which means we’re accessing a remote server, followed by add and name we choose, which we’re calling origin (this is a common industry standard), then the URL of the remote server we want to add. Then we’ll use the command git remote -v to verify our connection.

Do you see a problem here?

The eagle-eyed among you might have noticed my primary branch (denoted in blue text in Git Bash) is called master locally but main on GitHub. This will cause conflicts, so it’s a good thing we caught it now. Before we do anything else, we’re going to change that name to reflect the modern convention.

The easiest way to do this is to close the console window, open the .git folder in our project inside Windows Explorer and change the file named HEAD in Notepad or your text editor of choice.

Make sure “Hidden items” is ticked on in the View tab if you don’t see the .git folder

When you reopen Git Bash you’ll see the branch name has updated to main.

Pull -> Commit -> Push

Now we can use the git pull command to merge the files from origin into main.

Sometimes it tells you your password was wrong when it was not wrong, so you insist and it listens

This pulls everything from our server into the current project, but it does not automatically add the files in our project to the git. Check what needs to be added with the git status command, then add everything with git add ., being sure to include the period after add.

You can also add folders and files individually… if you hate yourself

If you’re working on a team with multiple branches, it’s important to always pull the most recent commit before pushing yours to the server. Even if you’re working solo, get accustomed to this workflow.

Now that our changed files have been added, we can lock in our changes with the git commit command with the -m modifier so that we can include a message briefly outlining the changes made.

The notes are for future you, who won’t remember what you did

Finally, we’re going to push our commit back to origin to create a record of our progress and a return point should we need to go back to a previous state in our project.

It’s still the same password, GitHub

Back on GitHub, we can see that everything worked.

Project as it appears on GitHub

Great, You Know Everything Now!

We didn’t cover branching, merging, reverting or resetting our projects here, but this is enough to get your version control up and running.

We’ll come back to those other topics in shorter posts in the future.

--

--

Mike Bischoff

Author, motion designer, Unity developer, my producers’ favorite freelancer