Saying: Branch early Branch Often
Basic Commands
branch displays all available branches
branch <name> makes a new branch with the given name
switch <branchName> moves you to the branch with the given name
git branch
git branch dev
git switch dev
Now below I’ve typed these out with a few extra ‘git branch’ commands so you can see the dev branch being created and switched to.
If you check the blue text at the end, you can see after switch we now are in (dev)
This is the basics of the command, but what’s so cool about it is what happens when we commit a change and swap back.
Testing out Branches
At our Local Repo location (our project folder) add a blank notepad text file called ‘dev’ (full name dev.txt). Run our ‘git status’ command to show it’s in the project needing to be added and committed.
git status
git add dev.txt
git commit -m "testing branches"
Now let's do something crazy.
Let’s switch back to our main branch with the command
git switch main
and behold the dev.txt file is gone.
And if we switch to dev the dev.txt file will return!
Now the way this conceptually works if we wanted to recreate it with just Windows is if we copied the folder, added dev.txt to one, and just swapped between the two. But Git knows (dev) branch only has 1 unique file, so it knows it can borrow from the past commits or “Versions”.
And once you know how feature branch merging works, you can start to see the real power of Git when working with team members.
Feature Branching and Merging
Feature Branching is a specific way of working. Where we make a branch for a new feature, or maybe a specific bug we’re trying to fix.
So let’s
git switch --create player_health_UI dev
Ok, big command! But it’s actually two commands combined to save time. Lots of other shortcuts like this exists, a simple change to the above is replacing --create for the shorthand command -c
What the command above is doing
“Create” a new branch called “player_health_UI” and create it off the “dev” branch, then switch to the newly created branch.
As the branch name applies, we’re now focused on a “Feature”. Adding the player_health_UI to the game. For this, I’m just going to upload a .png file to simulate that I did the work.
You can do any changes you want but if you want to follow along just make a healthbar.png and do your normal add and commit as shown below.
Finally, to merge we simply switch to the branch we want to receive the new changes, and then say which branch you want to merge
Now if you forgot to push that’s ok, we can still push after merges! Even though we merged we want to make sure everything gets pushed up so we can track it on GitHub better, especially as you may do 2 or 3 commits within your “Feature branch” before you merge. As in real-world work you might spend a few days getting the player_health_UI feature just right before merging it into the dev branch.
git push origin player_health_UI
git push origin dev
And we’ve done a merge!
How most teams like to work is to work on features separately, completing them to a complete point, and then merging them into the development branch for team members. This way team members should only have to deal with merging with complete features, not half-done code or art that needs to be re-tweaked.
And the Git Tutorials are done for now,
Where to learn more
The Git community is huge, there are tech blogs dedicated to only talking about git weekly over years. So if you ever get stuck you can almost always google or just ask how to get something done.
The biggest thing is just getting used to using Git.
If you really want to dig more though...
Atlassian has some great guides talking about different Git Workflow and different ways teams do things.
I personally like the Git Flow method, which is an evolution of the Feature Branching workflow. I like Git Flow as it’s all about being able to release builds frequently even if it’s only to a test server for internal QA.
Example of GitFlow below
Catch tomorrow's tutorial as we dive into more C# and Unity3d code over the coming days.