My Struggle to Commit (A Git Valentines story)

I’ll admit, it’s probably a stretch to call this story a romance; nevertheless, my personal and professional life changed quite markedly after our introduction.

Every good story has a healthy context to it, so let me start there:

I’ve always found programming to be something of an experimental science. Best practices, strategies, and design patterns are born out of the fire of chaos, and through the foggy flames of confusion and glee, new programmers were born, like me.

For many of us who learned to code in our mid-20s, our initial introduction to code sprang not so much out of curiosity but out of a need to solve a particular problem.

The interesting thing about solving problems is that the solution is often influenced not only by our teachers but also largely by our life experiences, thought processes, and idiosyncrasies. As a result, solutions for particular problems are often solved very differently depending on the individual who solved them.

Another simpler way to say this is: British Roast Chicken is leagues away from Jamaican Jerk Chicken 👀 🤫 👀

Now back to my problem.

Since programming is so often experimental, progress is commonly incremental - meaning we don’t do everything at once. A program is classically developed through three repeated steps:

1. We write code.
2. We review the code we wrote.
3. We improve what we write based upon that review.

At any time however between steps 1-3 we live our non-computerized life. We eat, drink, sleep and enjoy the fruits of life.

When we power back on our mystery machine we are often faced with a new class of problems. Our lapsed memory...😅

Programming, you see, can get very granular; we keep a lot in our RAM (short term memory) as we write our code, thus when we return to our computer after a break, the specifics regarding what or maybe how our program works might end up being forgotten. After particularly long breaks it feels sometimes like somebody else wrote your code.

This is why it’s good to keep a record of your code at each step.

When I was studying in university, I used Microsoft Word to write all my essays. These all required a lot of reading, study, research, and review to complete, so it would often take days, weeks, or months to finish.

When my work was being reviewed by a professor, I would still take stabs at editing my essay for improvements and so I would make changes. Those changes would be labeled differently for the various experimental versions of my essay.

Pretty quickly I had folders full of documents named like this:

Essay.doc
Essay_new.doc
Essay_new1_doc
Essay_new_2021_final.doc
Essay_new_new_current_20201_final.doc

Eventually, when my professor handed back my essay it would be marked as Essay.doc - Clashing with an existing file on my computer.

To solve this I often renamed it to something like Essay_first_one_prof_review.doc - Terrible naming convention I know.

I imagine you can see where this gets messy right?

I know what you’re thinking, couldn’t I just filter through the date_edited column on my file system? It’s true I could, but that still doesn’t tell which file has which changes and doesn’t help me consolidate all those changes together with my professor’s suggestions into one document.

This reconciliation process was handled manually with much pain and toil burning the midnight oil at my computer.

Programming arguably requires more written precision.

Thinking back to all those horror stories experienced at university, I thought I might try an alternative method to mitigate this now as I write code.

This solution would enable me to share different versions of my code and would ensure I would only keep one version of the code on my computer.

What was it called you ask? Slack🙈 🤣.

I thought I was smart. You see when I would write my code, I would upload it to my personal slack channel. If I had experimental versions, I would upload those so that I could always compare between any given working version when required. Differences between files were accomplished by manually downloading the files, renaming them, and then comparing them by using diffchecker.

After going through various versions of my code and returning at times to projects months later, I found that I'd completely cluttered my slack channel with different confusing same-file-named versions.

Sure, you can search through slack channels, but slack is not designed to search through code. I'll say it for all the people in the back: Slack is a poor man's search engine, so don't use it as one.

I'll proudly affirm that Slack is a great tool for communication, but as a tool to store, search, and version code, it is wholly insufficient.

But then I found git...and just imagine, imagine finding something, or someone who can help organize your mind, helps you remember important things, empowers you (and your code 😛) to be the best version of themselves?

That's love.

And so my git romance started with just two simple words: git init...

Join me in the next episode as I explore how git became the perfect solution for all my code management problems and how you can spice up your developer life with some git romance!