Branches, branches, and more branches
Now, I have these two branches called “main” and “master” which are essentially copies of each other. In a more realistic situation however, I would have more branches separated by major parts of the game that are being worked on. So, lets make some more branches and see what actually happens when you work on multiple and switch between them.
Speaking of which, “git switch” is how you switch between different branches. We had previously used “git checkout”, however, Git seems to want you to use “switch” now as “checkout” is not even listed in the --help any longer.
What about making a new branch? Its simply “git branch <branch name>”. If we do just “git branch” it shows us what branch we are currently on in GREEN, and lists us the current branches in the local. As you see here, I have made an additional “dev” , “inventory”, and “quest” branches. Pretty simple!
Now here is the really cool part about all of this. Lets say I made a new script while working on the inventory branch. That script is ONLY on the branch I made it on. This means that if I switch to another branch, on the fly, in unity the file will disappear! If I switch back to the inventory branch, it comes back. This ability to be able to switch between different versions and instances of a project is one of the coolest things about Git. “There's a bug in the inventory branch.” Well, at least that bug is relegated to only the inventory branch as long as we didn't MERGE the two branches before bug checking. Our main branch is the main branch for a reason. It is the version of the game that should be stable, and the version that would be published. Using branches is a extremely productive habit to get into.
Wait, I just talked about MERGING didn’t I? If you want to essentially have a branch, update to match another. You simply switch to the branch you want to update, and then you do “git merge <target branch name>” This will essentially auto COMMIT the changes copied from the target branch, and put them in the the branch you are on. All that is left to do is PUSH. Interestingly, the updates on the GitHub will match the original PUSH times from when it was done on the target branch. In the example above, I have merged my inventory branch, with my main branch. Now the two are essentially the same!
Lastly, what happens if I messed up. I COMMITTED and PUSHED some things to the main branch without checking to see if the game works. Now I have broken the entire project! How do I fix this?
If we do “git log” it actually shows us a full history of all the COMMITS, that were done on the repository with a commit id number. Lets say I want to revert back to a certain point such as when I COMMITED the Cube 3d object.
I can highlight the id, copy it, and then while I am on my main branch, do the following command.
I have now hard reset the branch main to that point in time of the COMMIT. It even tells me that this branch is now behind by 2 COMMITS. If I want to PUSH this to GitHub, I have to FORCE it with the following command.
If I do this, my main branch will revert to that COMMIT and I will lose everything that occurred afterwards.
Now this can be extremely dangerous. You could lose days and months of work if you blindly do this.
An amazing thing that you can do is actually switch to the logged COMMIT like it was a branch. This is done by simply doing “git checkout <commit log id>”. This way you can test on that version, and see what you need to do.
You can go even further and make it into an actual branch by doing
So if I do “git switch -c old-project-state <log id>” and check git branch, I now have a new branch for that commit state, and I can use it like any other branch!
Now you are playing with POWER.
I have learned quite a lot about the usage of Git and GitHub through this little mini test. The program to be quite honest amazes me and I am sure I will be using it quite a bit for the future to come.
Now however, it is FINALLY time to get to some Game Development!
Thank You for reading.
See you next time!