Nov 29, 2020
Git Pull, Git Rebase, and my Village People
Love at First Sight
After a failed, but impactful, attempt to launch my tech career during my university’s IT period, I took the biggest risk to make an expensive last push after my service year in 2019. In that year, I got introduced to OOP through PHP and Git. PHP excited me because it was the first time I would be trying out making a web application dynamic and interactive with a database. But, I swear down, it frustrated me a lot and my colleagues at the Bootcamp we attended would agree. However, for Git, it was love at first sight — at least for me.
Imagine coming from a planet (not that I’m an alien or wish to migrate to mars but you’ll get the gist) where documents, data and records had to be transported via drives; be it an external hard drive, or USB to get them from point A to B. Remember having to wait for minutes(depending on the port you are using and the size of the file you are transferring. God help you if you choose the slowest port) to transfer data of over several gigabytes. Or tech folks favourite of naming projects in funny titles( Iya Biliki Design final, Iya Bilikini Design Last Final, Iya Biliki Updated Final, Iya Biliki Final final…) just to define and remember an established backup.
Suddenly, out of nowhere, you are introduced to 3 lines of instructions;
git init
git add .
git commit -m “Commit message”and just like that your codes or projects are staged and tracked for changes. Are you kidding me? These commands ridicule the process in the previous paragraph and make it look like a joke. Like, holy moly, where have you been all my life? Wish I’d met you sooner (hmm, mmm, here we go again with the smooth line of lies). Of course, it took a while for me to get used to her(Git) syntax and to always remember to commit my changes. Can’t blame me really, I was a village boy just to used too the old way of doing things. But the idea of her was thrilling, sexy and I remember almost always having a smirk at the corner of my lips every time I had to flirt with those commands looking them up from the notebook I had jotted them down.
Ok, Time to Meet Her Family Members
It wasn’t just enough to be flirting around with git in my local, I needed to push my commits into the cloud(was so tempted to write cloud nine, ok I wrote it already) to stay more secure and to join a larger network of professional developers. Imagine meeting a developer that doesn’t use a git repo online; like… phew, let’s not talk about that today.
So, that was how I got to meet GitHub, one of many family members, the software development and version control tool. It provides access control and several collaboration features such as bug tracking, feature requests, task management, continuous integration and wikis for every project. This introduction necessitated I learned newer and a little less straightforward commands (at the time). Commands like adding an online repo to a project (or even starting the project by cloning it), creating branches and knowing how to traverse through them without messing things up. And to be honest, this caused me migraines(not literally) and I just stubbornly stayed committed to committing(pun intended) and pushing to the master branch. This would land me in hot soup in the future but I was naive and too blind to it at the time.
Trouble in Paradise
What’s the max you can go before all the thrilling sweetness and romance in a new relationship is finished and you guys are back to earth? For Git and I, we managed months. So, for over 9 months I survived having my way and pushing as I wanted. If I encountered any conflicts I fell back to my favourite command,
git push — forcewhich to be honest can cause a lot of harm, especially if you are naive. This, however, won’t continue for long after I started an internship with Decagon, a subsidiary of an international company, L5lab.
I moved from working as a one-man mopol to working with a team of developers. This had implications for me (that would help me grow but first I had to learn my lesson the hard way) that included, working from my branch of a project and creating a pull request (PR) to be merged with the stable branch. Also, I had to consistently pull from the stable branch of every project’s GitHub repo to update my local before branching out to another feature or before making a PR if there were conflicts between the remote repo and my codebase. Learn more of that here…
One of those days, my team was working hard to meet up with a deadline we were almost done and I just needed to finish up on an important and needed feature for our Minimum Viable Product (MVP) presentation and then, my unlucky ass happened.
I had written a lot of code, committed but hadn’t pushed. When I tried to update the repo, there were conflicts and in the rush, I googled the warning messages and instructions from git, stumbled on a Harry Maguire’s (not the real StackOverflow’s username) comment on using StackOverflow on using
git pull — rebaseWithout checking out git’s documentation on how that works, or even reading more on the command, I just plucked and plugged it into my terminal. Different prompts came up and I gave consent without reading in between the line or understanding the hell I was doing. Five minutes later, my stupid cover was blown and I started sweating — like Christmas chicken. Whatever I had done, wiped off all I had written in the important feature branch, dragged my ass halfway across town to an older commit and left me without a choice to rollback. Not because the command was wrong, but I didn’t do my homework well enough to know how to use it right. I’m pretty sure I blamed my village people for that because that day was all shades of wrong from the get-go. Maybe the omen should have kept me away from an important codebase, but I couldn’t, my team needed me. I nearly made us look like a bunch of failures with our sorry faces staring off a billboard with the caption: Never write code like this ones. Of course, there was damage control but I would talk about that in a later post on how to take advantage of GitHub Desktop.
Making Your Relationship Enjoyable
It’s not what you are thinking. I would just bite humble pie and say this: Learn not to write git commands as I did in my early days. If you’re a newbie in the development, learn it right from start. I would point you towards helpful articles on that and of course the documentation itself. If you’ve been coding a while now, don’t fall into the tempting pit of plucking off some git command written by a Dick or Harry Maguire on StackOverflow or any other dev blog without fully understanding what it does, how and why you should use it. That, I’m sure will make your relationship with Git more enjoyable and exciting.
Some Helpful Links Below on Using Git With Ease
