Using GitHub

Jordan Evans
Apr 24 · 7 min read

Now it’s time we get into the nitty gritty of GitHub, and what it can do to make our lives easier.

Linking to Projects

Once you have your repository created, you will want to link it to the project. In order to do that, you will want to add the URL that was made for that repository:

Git URL

From there, you will want to go to your Unity project. The long method is to open up Git Bash, and navigate your way through the program to get to the project:

Creating a list that you can call down in Git

When you first open up Git, and you don’t know the exact item you wish to call down, you can type ls to create a list to populate your options.

Calling down to your project.

Once you have found the option you wish to choose, type cd then your option. As Git uses \ to designate space, a simpler method is to push tab after entering in the first couple letters, and it will auto-populate your desired result. Keep repeating the process until you open up your desired project.

Alternatively, you can skip the whole search through Git and open up your projects location through Documents folder.

Once you have opened up the folder, we will now right click on the screen and open Git Bash Here.

From here, we will be greeted with this window:

Once we have opened it from the project location, you will want to type git init to initialize to communicate with anything you want to do and track your project. After this, you will want to add the web server that you created earlier to the repository. We will want to type “ git remote add origin” then paste in the URL address that was copied earlier. Origin is the industry standard for the server name.

To verify what you have done, you type git remote -v, and it will show you that you have a connection to the server. There is a chance that it will prompt you to log into GitHub.

Commits

One of the biggest issues of people using version control for the first time is the order in which someone does things. You can’t just commit it in code while ignoring whatever else is happening on the server, as it may have information on it that you need. The best way to avoid massive headaches with merge conflicts is to: Pull from the server, commit and then push. If you follow this order, you are a lot less likely to create issues.

If we ever want to know what commands are available to us, you can simply type in git — — help to view your options:

List of options for help command

From here, we will start our pull.

From here it will ask you what branch you wish to pull from.

A recent change that was made with GitHub is the replacement of “master” with “main”. This was done as to make the wording sound more inclusive for all. Once we have pulled, you will notice it says Fetch_Head. The head is front, so it will be the latest commit by default. From here, we can check the status:

As we can see, the files are in red, which designates that they are not being tracked at the moment. To include all of the changes that you want to commit, you will have to add the files in which you want to include in the commit. You can go 1 by 1:

Or, you can type “git add .” and all of the files will be added to the commit.

From here, we will want to create a commit by typing “git commit -m “Message for commit” ” The message that you put is what you just worked on.

After this has been done, we will now need to complete the last step and push the commit. If we just type git push, it will prompt us to select where to send the push to.

We can now go over to GitHub and see the update to our repository, and all of the files we just committed will show up.

Branching

Branching is a very important subject with version control. A lot of pros will say to branch early and branch often. The reason is because it is lightweight, and allows you to work parallel with other teams. What can be done is that you can retain the master branch for the released version of the game, while having a dev branch where you make all the upcoming changes to the game in. From there, you can branch it out even further, and break a part the workload to multiple smaller branches.

Example of a branch system.

As we can see from above, you can split the dev branch into smaller parts so that different teams can work on different parts of the game at the same time.

To create or switch branches, it is rather simple:

For creating a branch, all we have to do is type git branch ___ .

To switch a branch, one can either choose to type git checkout ___ or git switch ___ . For those that are older to the program, they will remember it as checkout, but another update to their system recently has changed that term to switch.
As to what it means when you are in a different branch, you are able to add to that branch without affecting the other branches.
Once we have done all that we want to do in the branch we are working on, the next step is to merge it into the upper branch. In this case, if we were to add to the inventory, we will have to commit the changes, then merge with the Dev branch.

New files in Git for changes
New scripts added to Inventory branch
Master branch without new scripts

As we can see, while in the inventory branch, we added a couple new scripts and committed them. However, if we switch over to the master branch, those new scripts will not show up until we merge the branches together. To do this, we simply just type git merge inventory while sitting in the master branch.

Master branch after merged.

Once we are done merging and committing everything locally, we simply push it to the main server and it can be used however one wishes.

Reverting vs Resetting

When it comes to reverting or resetting a branch, it all comes down to if you want to hard push a previous state, or if you want to just save an older version into a new branch, see what was done there and decide what changes you wish to have done. The safest method would to be reverting and putting an old commit as a new branch to view, but if it is something that needs to be done immediately, than resetting to a previous version is required.
At first, you will want to check the log of the commits that were made.

From here, you can just copy the code of one of the commit logs and search it as a branch:

After, all we will have to do is make it as a new branch is type git switch -c _____ (new branch name) and paste your code here:

Now we have the older version as a stand alone branch, and you can see what was done there, and follow the merge steps from earlier to add it to the master file, if you need to revert the changes that were made.

Alternatively, to reset your project it’s just a couple quick steps:

Resetting to previous version

We will simply just type git reset — — hard ________ , after that we will now force a push to the origin by typing git push — — force origin master.

Now that we have a good understanding of how to use GitHub, we can now apply our new found knowledge and implement it to future projects. Stay tuned for some more content, as we start to explore the creation of a space shooter with some old Galaga vibes to it.

Nerd For Tech

From Confusion to Clarification

Nerd For Tech

NFT is an Educational Media House. Our mission is to bring the invaluable knowledge and experiences of experts from all over the world to the novice. To know more about us, visit https://www.nerdfortech.org/.

Jordan Evans

Written by

Nerd For Tech

NFT is an Educational Media House. Our mission is to bring the invaluable knowledge and experiences of experts from all over the world to the novice. To know more about us, visit https://www.nerdfortech.org/.