GitHub Guide

Handling branches of a GitHub repo using Git Bash

A quick guide to handle branches in your version-controlled project

Hi! In my last post I talked about how to make a commit for your GitHub repo using Git Bash and now it’s time to see how can we handle branches in our GitHub repo using Git Bash too.

So, what is a branch? A branch represents a way in which a commit, version or snapshot of your project’s code have the opportunity to be developed in several features without compromising the current state of it.

For example: if you were developing a game like Fortnite you will probably need a lot of branches as it has a lot of features incorporated like construction, edition, shooting, player movement, player interactions, player outfits, store items, live events and more.

By default, when creating a new GitHub repo, we have a default branch called master (or main in new repos) that will contain the first version of our project code. In Git Bash, we can display the branches of our repo using the git branch command:

When using the git branch command a list of the branches of our repo is displayed and a * is included at the left of the current developed branch

Creating & switching branches

Let’s say that we are developing a Unity project (like in older posts) with a single script in its files and it looks like this:

We have a single script named Challenge in our Unity project

To create a new branch for the project we need to execute the git branch command again, but adding the name of the branch we want. In this case, we can create a new branch dedicated to develop a new feature in our project called DevBranch. Note: it’s important to notice that the new branch will be a copy of the current branch (master) we are developing.

After creating the DevBranch we can execute git branch command to display it in the list of branches

Once we created the DevBranch we need to use the git checkout or the git switch command to switch the current developed branch, which will appear in blue (in front of the directory) or in green with a * after displaying the branches list with git branch command:

After switching the branch with git switch we can see the name of the current branch in blue

As we are currently in DevBranch (a copy of the master branch) the Unity files will look the same, so let’s add a new script named DevBranch:

The new DevBranch script will suppose a change in the files of the Unity project

Now, as we did in the last post, we should commit our changes to save the branch changes that we have.

Note: just commit the changes, don’t push them yet

Next, we can try switching to our master branch again and we won’t see those changes inside our Unity project:

Switch to the master branch again using git switch master

The Unity project returned to the master branch state, as there were no changes in it, just in DevBranch.

So, if we switch back to the DevBranch, the DevBranch script we created before will appear in the Unity project.

Merging branches

Another important feature to handle the branches in GitHub is the merging of branches. Once a branch has reached the production state or its goal we can merge it with another branch to join the features of both in one single branch.

We will also need an inventory feature or our Unity project, so let’s create a new branch named inventory:

List of all the branches in our repo using the git branch command

Then switch to the inventory branch:

Switch to the inventory branch

Let’s say that in order to start developing an inventory we need to have the features of the DevBranch in our inventory branch, so we must merge them using the git merge command:

Merge of the inventory branch with the DevBranch

Now the inventory branch contains the features from the DevBranch and can be developed using those features. So once the inventory is developed (I just added an inventory script) we can get back to our DevBranch and merge it with the inventory branch changes:

And, once DevBranch is merged we must push the changes into the GitHub repo to see the actual changes in files and branches we did. We can see that when we try to display the untracked files in our DevBranch using the git status command, a message says that there’s nothing to commit, but if we don’t push we will only have merged the branches locally and no changes will be reflected in GitHub.

Using git status displays that there are no commits to be pushed but we need to push them to update our GitHub repo.

Note: it’s important to push the changes in every branch as they are separate versions of code and will be reflected in its own state in GitHub.

Once we push DevBranch we will see the changes in Github, where the master branch will only have one script and DevBranch will have 3 scripts (one from master, one from inventory and one from its own branch).

The master branch still untouched as it wasn’t merged with another branch

The DevBranch is now visible in GitHub as it was pushed (inventory wasn’t pushed)

The 3 scripts are inside the DevBranch as it was branched from master and merged with inventory

And that’s it! your branches should be published in your GitHub repo. I’ll see you in the next post, where I will be showing how to recover or start working in a previous version of our GitHub repo to avoid failures in your project.

If you want to know more about me, feel free to connect with me on LinkedIn or visit my website :D