Earlier in my academic career, I had learned to use version control. After a few years without using it, I was feeling rusty, so I chose to proceed on Udemy courses without version control.
I was learning to code a top-down shooter microgame, and I chose to upload the progress.
After sharing this in one of the Unity learning communities, I was asked if I had been object pooling.
Having never heard of object pooling, I came to learn that Instantiate and Destroy are rather resource intensive, so for a game like a top-down shooter where you are using ammunition and spawning enemies, a weaker device may struggle to keep up.
Object pooling, in turn, recycles and resets the attributes on various objects rather than destroying them when they've been used. So in the case of ammunition, you could have a pool of ammo that keeps being recycled, instead of spawning a new ammunition each time the player shoots.
How does this relate to version control? Well, I made the mistake of trying to implement object pooling in my prototype's only source code. When I messed everything up, I didn't have a way to get back to where I had been before.
Frustrated, I decided to try GameDev.tv's Git course. It was relatively short, and I got through it in a weekend. It introduced me to SourceTree which I find to be much cleaner and straightforward than Github Desktop. Having been refreshed on version control, I felt confident continuing my learning.
Fast forward to my work on the Tetro Breaker project, and I utilized version control heavily. From writing the prototype along with the course, to adding all of the extra features and levels, I commited each step along the way.
Given how many commits I had to revert, I'm rather satisfied with my decision to relearn git.