Tag Archives: GitHub

How To Setup A Github Repo For A Unity Project

Edit: Fixed link to git ignore file (10/14/21)

If you’re not familiar with using Git you can take a peek at my quick guide Git It? or spend some time browsing the web to get familiar. If you are familiar with Git, you will need to install Git Bash for this tutorial. You can grab a copy of all the necessary install files right here: https://git-scm.com/downloads


The first thing we want to do is setup our new repository on Github. You will need to first create a Github account. Once you’ve created your account, you can click the little plus sign, in the top-right corner of your screen and select ‘New repository.’

This will take you to the ‘Create a new repository‘ screen to setup your new repo. You will need to provide a name for your repository and then select if you want it to be viewable by the general public. In this example, I will keep the repo private.


I do not want to create a ReadMe or .gitignore at this time but I will do so after I have created my Unity project. Go ahead and press that little green button, ‘Create respository.’

Now that the new repo is setup, Github will kindly provide you with some instructions on how to push your new project to this online repo.


But the first thing we need is to setup a new Unity project. I will walk through how to create a new Unity 2D project and then we will setup a .gitignore file to exclude any files we don’t want to include in our repo. Finally we will push all of our changes up to Github.

Let’s walk through the process.

You’ll want to open Unity Hub and create a new project.

Now that the project has been created you’ll want to navigate to the directory where the project has been saved. Once you are in the directory, you can right-click and select, ‘Git Bash Here.’ This will open the git command line.


The first command we want to run is ‘git init‘ this will initialize the git repo locally and allow you to start adding and commiting your unity project for source tracking.

Now that the repo is setup, we can run ‘git status‘ to view the files that we can potentially add to our repo, BUT before we add anything, we want to include our .gitignore file. This will allow us to only include the files we need, and allow us to ignore any temp or unneeded files.

To do this you will need to create a new empty text file and rename it to ‘.gitignore’ so that git will recognize this file as being the one that will tell us which files to ignore.

Now go ahead and open up the file in a text editor and in the contents of the text file we are going to include the files we wish to ignore. You can find a good example of what to include by searching on Google for a Unity .gitignore file or you can use the one here: https://raw.githubusercontent.com/github/gitignore/master/Unity.gitignore


Once you’ve added that to the contents of the .gitignore file, you can save the file. Back in the git command line window you can run the ‘git status‘ command and see the remaining files we will include in our repo.

We will now run the ‘git add .‘ command which will include all of the files that are not ignored, to be a part of our project.


Next we will run the ‘git commit‘ command which will commit our newly added files to our main branch. We will actually use the ‘git commit -m‘ command so we can include a little message on what these changes are.

After adding our files it’s time to finally push them up to Github. To do this we will run two more commands. The first is the link this local git repo to the one on Github.com. The second is to push the changes from our machine, up to Github.

Github provides the first and second command for you:


Execute the ‘git remote add…’ command followed by the ‘git push‘ command (you may need to change the push command from ‘main’ to ‘master’) and you’re done.

You now have a brand new Unity project on Github. If you’re interested in knowing more on how to work with Git or Github leave a comment!


Developers tend to be really great at writing code but not so great at documenting that code. It’s not that they can’t or don’t want to, it’s that often times the effort to write that documentation isn’t captured within the scope of the requirements for the feature.

But as developers we shouldn’t let that stop us!

photo cred: Shahadat Rahman

I’ll share a couple of good reasons to document your code and some really easy ways to make it happen. While we’re at it, let’s stop using the gross word “document.” What you want to write is a solid README!

Why You Should Document Write a README:

  1. Writing a README gives you a means to not be the sole owner of that code. When you have notes around how your code works, what it intends to accomplish, and how others can contribute the project, it stands a much greater chance of getting additional buy-in from other developers and stakeholders. When you’re the only one who knows how it works, be prepared to be the only one whoever gets asked to work on it.
  2. Writing a README for your code helps you be able to come back to that code and remember that one piece of how you set it up originally. It allows you to go back 6 months later and say, “Why the hell did I do it this way… Ohhhh… right… here’s why.” Save yourself, write a README for your code.
  3. Writing a README for your code helps you think through the scope of your project and its functionality. It helps you take a step back and really consider what you’re doing and why you’re doing it. It helps you put that official stamp of approval that you’ve completed this version and it is DONE. Scope creep is dangerous, writing a README on the current state of the project and any potential future work can help keep that project from living forever.

How You Should Document Write a README:

  1. README, README, README… most source control services provide some extra functionality around writing README’s. Some really great ones like Gitlab and Github will display the contents of the README in a web browser making for easy access. If you’re not using source control, YOU SHOULD BE!. If you are using source control, you should be writing a README and including IT with your source code.
  2. There are some great README templates out there! Save yourself a ton of headache and find one that works for you. A template gives you a head start and helps you focus in on what you need to cover. It also helps maintain the scope of your README. Here’s one that I’ve used: https://github.com/othneildrew/Best-README-Template
  3. Don’t just rely on a template. Use the template as a starting point, but think about what is going to be important for your team, users, and stakeholders to know when viewing your README. Do they need to know how to set it up? Do they need to request any special permissions from anyone? Can you reference other documentation that might help give them a deeper understanding? Try to think of your README as being something you can hand to another person and they do not need to come back to you with questions.
  4. Maintain your README. As you do get additional questions on the project, update your README. Add a Frequently Asked Questions section or fix that typo. Include an area you may have missed from the first pass and encourage others to contribute to your README. Continue to build into your README as you add new functionality to your project and just remember to Keep It Simple Stupid.

README’s often get skipped over as we jump from project to project. I’ve been guilty of missing out on including them before but I’ve also seen the advantages of including them and I’m working to continue working on them.

The best place to start is to just start. Go grab a README template, paste it into your project and fill it out bare bones. From there you can build on to what you’ve started and the next thing you know, you’ll have a solid document around the who, the what, and the why.

Happy Coding!