- Random Access Musings
- Posts
- Tracing Our Steps: A Guide to Git (Part 1)
Tracing Our Steps: A Guide to Git (Part 1)
Adding To The Toolbelt

This is a series of 6 posts about using Git.
The Big, Bad Dev Tool
Let's talk about git. It's okay, it's not as scary as it sounds and while it's primarily a developer tool, it's not because it's only good for code. In reality, it's a tool for managing any type of file or project that undergoes changes over time, making it perfect for scripting and anything primarily text. Server configuration file? Or a shell script that you need to modify? Git can provide an invaluable safety net. It gives you the ability to track changes, compare versions, and if necessary, revert to a previous state. It can also be a lifesaver in the event of a major problem (none of which has ever been caused by human error, ever). In these totally-not-human-caused situations, it can provide a clear history of what was done and when, by whom. But first, let's break down exactly what problem it was designed to solve.

What problem does this actually solve?
Imagine you're writing a fantasy novel - starting with a simple idea, expanding it into a universe filled with characters, stories, and intricate details. As you write, you revise chapters, tweak character arcs, modify plot points, and sometimes, completely overhaul entire sections. Now, picture this - for each modification, you need to keep track of what was changed, why, and when. Traditional ways would involve a confusing mess of drafts, stacks of paper (or files, digitally) with various changes, and branching paths for where you want your story to go.
But imagine you had a magical journal. This journal not only lets you write your novel, but also keeps a detailed record of every single edit made, by whom, and when. Made an update that doesn't quite work? No problem, this magical journal lets you turn back the pages to any previous version of your story. Want to know how a particular character's backstory evolved? It's all there in the journal's records.
That's what git is for your projects and files. It's your magical journal that ensures your work is always organized, traceable, and most importantly, reversible. It's not just about managing code, but about managing changes, regardless of the content type.

But do I have to use Git? Isn't there something else?
Let's take a tour through the alternatives, some of which you might already be using, to underline why they might not be the best option for version control:
1. Manual file versioning: You've done this. Don't try to hide it. I've done this. You've got your script_v1
, script_v2
, script_final
, script_really_final_this_time
, and so on. Although it might seem simple, it's far from efficient or foolproof. This method is time-consuming, error-prone, and can quickly turn into uncontrollable chaos as your files grow and modifications increase. Imagine trying to find a single change in an ocean of vaguely named files. I know I'm not the only one who's ever wondered what script_v2.2_fix_loop_for_real
actually does. And what if you need to share your work with someone else? Enjoy zipping up and explaining your naming convention to a teammate.
2. Shared Drives (Dropbox, Google Drive, etc.): Cloud-based file-sharing platforms offer some level of version control. They auto-save changes and allow you to restore previous versions But they have limitations. You can't label versions, making it hard to remember what each version contains. Also, the history is often limited, meaning older versions may eventually vanish. Want to know who changed what? Good luck finding that information. Syncing files is also not entirely under your control. Not quite ready to save a version? Need to save a specific version right now? Not up to you.
3. Collaboration Software (Microsoft Word, Google Docs, etc.): These platforms have decent revision histories and collaborative editing. But their focus is primarily on content creation, not version control. Sure you might be able to find out when you changed something, or use a previous version, but running a Powershell or Bash script from an Office365 web editor is a bit more trouble than it's worth.
Each of these systems, while useful, comes with its shortcomings when it comes to robust, reliable, and efficient version control. It's like trying to hammer a nail with a screwdriver - sure, you might get the job done, but wouldn't it be much easier if you had a hammer? That's where git shines as the right tool for the job.
Hopefully, that's enough backstory to convince you that git is pretty invaluable for anybody working in tech. Its uses extend beyond raw software, into books, mechanical/electrical engineering, and, of particular interest to us, devops, CI/CD, and infrastructure-as-code. Next time, we'll jump into the nuts and bolts of using git. To be prepared you'll want to make sure you have git installed on your workstation. The Pro Git book is available online and has instructions to get started!
Keep learning and keep growing!
Darrell
Reply