Creating Branches in Git, and going back in time!

The beauty of using Git and GitHub is that it easily allows you to go back in time to a previous state incase you run into bugs, or just want to test out implementing a feature.

This is best done with branches, so that your testing/debugging does not affect your ‘main’ branch!

This is also the meat and bones of Git, so expect a longer read than normal!

Creating a new Branch

First, what I tend to do before creating a new branch, is to simply check what branches have already been created, as to not create duplicates and jumble up the GitHub repository.

To check your current branches, you can type git branch, and Git Bash will give you a list of current branches. You currently selected branch will be highlighted green, and also denotable by the light-blue text in brackets on your command line.

To create a branch, it’s as straightforward as typing git branch <name>. In this case I’ll be creating a dev branch.

Created a dev branch

Switching branches

To switch to different branches in Git, you can type git switch <name>. The older syntax used to be git checkout <name>, and still works if that pertains better to your workflow.

For the purpose of this next example I created a ‘DevBranchScript’ inside of our Unity Project. Staged it, and committed it to our local repo. (I did not ‘push’ to the remote server yet, so it would not be available online on our GitHub).

Created a DevBranchScript inside our dev branch.

Now, if we switch back to our ‘main’ branch, and click back into Unity, you’ll notice that our DevBranchScript is no longer in our project!

Where did it go?! Did we lose it?!… No! And that’s the beauty of Git!

It just has not been merged into our ‘main’ branch. It does not live here yet. Switching back to out ‘dev’ branch and you will see our new DevBranchScript is safe and sound!

Branches in Branches?!

Yupp, that’s a thing. It’s also a very productive and useful thing. Within your ‘dev’ branch you may want different programmers to be working on separate things. You can then create individual branches for them to work in.

In this example I’ll create an ‘inventory’ branch, and merge it (more on this later) with the ‘dev’ branch so that it inherits everything in the ‘dev’ branch.

You can see our ‘inventory’ branch has our DevBranchScript.

Now I’ll add an ‘InventoryScript’, stage it, and commit to our ‘inventory’ branch.

If we switched over to our ‘dev’ branch now, we wouldn’t have our new InventoryScript. But we want our current ‘dev’ branch to get our shiniest newest feature up to date, so we merge the ‘dev’ branch with the ‘inventory’ branch.

It’s important to note, that your current branch is the branch being merged into. In our example, our ‘dev’ branch is merging with the ‘inventory’, inheriting the changes within ‘inventory’. Kind of like grabbing outside of your current branch and pulling them in.

‘dev’ is now merged with ‘inventory’, inheriting the InventoryScript.

Pushing a new Branch

Before we push to our GitHub, we first have to initialize the new branch with a git file. You will get an error if this isn’t done.

So after committing your changes to your local branch(git add . , then git commit -m “<message>”), you can type git init.

Now you can type git push origin dev. This pushes the new branch ‘dev’, to the remote server (origin), and is now available on your GitHub!

Reverting to a previous state. Enter the Time Machine!

Oh no! You have a bug in your project! Where was it introduced? What now?!

Enter the Git Time Machine.

Reverting to a previous commit let’s you check and track down where bugs were introduced, or let’s you create a new branch from a totally stable point in time.

Let’s start by typing git log. This will bring up a list of previous commits that you may want to revert back to.

Find the commit you want to go back to and copy the commit code. Alternatively you can copy the commit code from GitHub, as seen in the second image, by clicking on your commits in your chosen branch.

Copying the commit code from Git Bash
Copying the commit code from GitHub.

Next, we’ll type git checkout <commit code>. This will revert things back to the previous state to see if this is the commit you’re looking for *insert Jedi hand wave*.

git checkout <your commit code>

Now if this is where you want to start working from again, it’s best practice to create a new branch, instead of resetting your progress back to here.

To do this we’ll switch to the ‘main’ branch again, then create a new branch with this commit code. In your ‘main’ branch, type git switch -c <name of new branch> <commit code>.

And now you can freely switch between your ‘old-project-state’ and your current ‘main’ branch! The time machine works much faster now!

Now you’re ready to take on the world of Project Management and really become a Git master!

A few things to remember:

“Branch early, branch often.”

“More commits = more points in time for the Time Machine.”

and lastly, “Pull, Commit, Push”, in that order, every time.

Good luck on your journey!



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Frank Warman

Frank Warman

Audio Engineer turned Unity Game Dev. Will be combining both my skillsets when appropriate, and will be documenting my Unity Dev growth in these Medium Articles