Git: How and Why to Branch
Part of the power of Git’s version control is the ability to branch a repository. Let’s say you are part of a development team working on a big project. You will always have a master or main branch. This will likely have the release builds in the form of commits. Now let’s say you’ve been asked to work on a feature, maybe something to be implemented later on. This is where you would branch.
Branching is to take the existing repository and literally, create a branch that separates any changes you make from the branch you took it from. If you have a master branch, you may then have a dev branch from the very start. Or maybe you will have a UIDev branch and a PhysicsDev branch and so on. This will become clearer with the following example.
In my Version Control example project from my previous article, you can see I just have the base files. I am currently still on the master branch in Git and I only have one branch. You can check the branches available with the command ‘git branch’ as below.
The list only currently contains the master branch and this is the active branch as denoted by the asterisk and the green colour. Next I will create a ‘master.cs’ script in Unity. I would not recommend using master as a script name, but this is just for illustration.
Now I will commit this to the repo. Remember, always pull, commit then push.
Okay, so now I have my master branch set up, I want to work on my UI for a while but without the risk of messing up my main project. I will create a new branch called ‘UIDev’ with the command ‘git branch UIDev’. After it’s created I need to switch to it to start working on that branch with the ‘git switch UIDev’ command.
In the above screenshot I have created the new branch, verified it was created with ‘git branch’, switched to it then verified I am now on the UIDev branch, again with ‘git branch’.
Unity looks exactly the same as on the master branch because we have essentially made a copy of it. Now I will add my ‘UI.cs’ script in Unity, then commit to the UIDev branch.
So now the new script is committed and pushed the UIDev branch. I’ll switch back to the master branch and show you the Unity assets again.
The master branch hasn’t been affected by the changes in the UIDev branch. The real power of this is that multiple people can be working on multiple branches without affecting each other’s work and without running the risk of breaking the master project.
As you can see in Github, we now have 2 branches and that UIDev has recent pushes.
So you’ve completed your UI development phase (and tested it thoroughly!) now you want to make the changes to the master project. You need to merge the branches together to bring all the changes to the master branch.
First you need to ensure you’ve committed all changes in the branch you’ve been working on (in this case, UIDev). Next, switch to the branch you are merging into (in this case, master). Next, merge the ‘UIDev’ branch into the master with the command ‘git merge UIDev’. Finally, push the master branch to the server with ‘git push origin master’.
This is what Unity now shows for the master branch:
And this is how the assets folder looks like in Github:
So the commit to the UIDev has transferred to master and we now have everything in the main project repo.
UIDev still exists and you can switch back to it to continue development but changes will again have to be committed and eventually merged to the master branch.
And that’s about it for basic version control with Git. In the next article I will look at viewing and manipulating previous commits if you need to go back in time on a project.
