You know that feeling when a project finally works, and suddenly you’re terrified to touch it?

Maybe it’s a script that took weeks to get right, a configuration that finally stopped throwing errors, or even a chapter in your novel that perfectly captures what you were trying to say. The project has become valuable—too valuable to risk breaking. So you find yourself tiptoeing around it, making smaller and smaller changes, or worse, avoiding changes altogether even when you know they’d make things better.

This isn’t just a technical problem. It’s a human problem. The more time and effort we invest in something, the higher the stakes become for every change we make. What started as fearless experimentation gradually transforms into cautious preservation. We become curators of our own work instead of creators, protecting what we have rather than pursuing what we could have.

The cruel irony is that this fear often strikes right when our projects need change the most—when they’re complex enough to benefit from refactoring, mature enough to need new features, or successful enough to warrant improvement.

The Time Machine Solution

“Good question. They can save their life up to a certain point and go back to it if they get killed,” said Lu-Tze.

— Terry Pratchett, Thief of Time

This line comes from Terry Pratchett’s novel “Thief of Time,” where Lu-Tze, a History Monk who manipulates time itself, is explaining the remarkable ability of the mythical snow yeti. Unlike ordinary creatures who face death with finality, these yeti possess something extraordinary: they can create temporal save points throughout their lives, and when disaster strikes—when something kills them—they simply rewind to their most recent checkpoint and continue existing from that moment, completely unharmed and with full knowledge of what went wrong.

It sounds like fantasy, but Pratchett’s matter-of-fact delivery gets to the heart of something profound: when you can safely undo catastrophe, you stop being afraid of taking risks. The yeti doesn’t fear death because death isn’t permanent—they can simply reload their last “save point” and try again.

This is exactly the mindset shift we need for our projects, and it’s exactly what a tool called git provides.

Git is a version control system—software that tracks every change you make to your files over time. Think of it as creating snapshots of your work at different points, preserving not just what your project looks like now, but what it looked like yesterday, last week, or six months ago. More importantly, it lets you travel back to any of those snapshots whenever you need to.

Git doesn’t just track changes—it fundamentally changes how we relate to change itself. When you know you can always go back to any previous version of your work, experimentation stops being dangerous. That script you’re afraid to modify? You can try ten different approaches and instantly return to the working version if none of them pan out.

Lu-Tze’s yeti has biological time travel. We have git.

The Misconception

If you’ve spent any time browsing the internet, you’ve probably encountered git without realizing it. Every time you visit an open source project on GitHub, you’re looking at git in action. Those repositories with their commit histories, branches, and pull requests? All powered by git.

But here’s where many people mentally check out: they see these impressive open source projects with thousands of contributors and think, “That’s not me. I don’t have a cool project to share with the world. I don’t even want my work to be public.”

This misconception—that git is exclusively for programmers working on open source software—causes people to dismiss a tool that could transform how they work on any project. It’s like assuming hammers are only useful if you’re building houses for other people to see, when really, hammers are useful whenever you need to drive a nail.

The visibility of git through open source projects has created this false impression that git itself requires your work to be public, collaborative, or even programming-related. But git’s core function—tracking changes and creating recoverable snapshots—has nothing to do with sharing code or building the next viral application.

You don’t need a repository that deserves GitHub stars. You don’t need code that other developers will admire. You just need text files that change over time and matter enough that you’d rather not accidentally destroy your progress.

The Universal Truth

The truth is simpler and more universal than the misconception suggests: git works for any project built from text files that evolve over time.

Writing a novel? Every draft, every character development, every plot revision becomes a recoverable checkpoint. You can fearlessly delete entire chapters knowing you can resurrect them later if needed. You can experiment with different narrative directions and compare them side by side.

Managing system configurations? Every change to your server setup, every tweak to your dotfiles, every adjustment to your network rules gets preserved with a timestamp and description. When something breaks after a configuration change, you don’t have to guess what you modified—you can see exactly what changed and when.

Maintaining documentation? Whether it’s internal procedures, user guides, or project specifications, git tracks every revision. You can see how your understanding evolved, restore accidentally deleted sections, and collaborate with others without the chaos of “final_draft_v3_ACTUALLY_FINAL.docx” files.

Working on scripts and automation? Even simple shell scripts or configuration management files benefit from version tracking. That working backup script from six months ago? Still there, ready to be referenced or restored.

The common thread isn’t programming expertise or public repositories—it’s text that matters enough to preserve and changes that happen frequently enough to track. If you find yourself making copies of files “just in case” or keeping multiple versions with names like “config_backup_working,” you’re already recognizing the need for what git provides systematically.

The Mindset Transformation

The real magic of git isn’t technical—it’s psychological. It transforms your relationship with risk.

Before git, every change carries the weight of potential loss. You approach modifications with caution, second-guessing yourself, making smaller adjustments than you’d prefer. You develop elaborate backup strategies: copying files before editing them, commenting out old code instead of deleting it, keeping multiple versions “just in case.” This defensive mindset creates clutter and cognitive overhead while still leaving you vulnerable to the very problems you’re trying to avoid.

After git, failure becomes temporary. You can approach changes with confidence because you know every previous state remains accessible. This isn’t just about having backups—it’s about removing the mental friction that prevents bold improvements.

The transformation happens gradually. At first, you use git as a safety net, making tentative changes while constantly checking that you can still revert. But as you internalize the reliability of that safety net, something shifts. You start making larger refactoring changes. You experiment with different approaches to the same problem. You delete obsolete sections without the anxiety of “what if I need this later?”

Eventually, you realize you’re not just preserving what you have—you’re creating better work because the fear of loss no longer constrains your creativity. The yeti’s resurrection ability doesn’t just prevent death; it enables a kind of fearless living that wouldn’t be possible otherwise.

My Journey with Git

My relationship with git started with blind obedience and took years to develop into understanding.

Thirteen years ago, as a junior software engineer, I was working on a project when my senior colleague casually mentioned I should use source control. No detailed explanation, no compelling reason—just “you should use this.” We weren’t even using git at the time, and we certainly weren’t collaborating through it. It was just something software engineers apparently did.

So I started using it without really knowing what I was doing. It’s surprisingly easy to fall into the pattern of committing changes, even when you don’t understand what those commits actually accomplish. For several years, I used source control blindly, not grasping that this tool could track changes, revert them, or create branching timelines. The concept was genuinely mind-boggling—how could software remember every version of my work?

Even after I finally understood how it worked, I remained trapped by the very misconceptions I described earlier. This was clearly a tool for software development. For programming projects. For professional code that mattered. I used it properly at work but never considered applying it elsewhere.

It took several more years to break free from those limitations and realize git’s universal applicability. Now I use it for everything: my editor configurations, tutorial code, learning notes, side projects, helper scripts, and yes, the content for this very blog. Each gets its own repository because each represents work that evolves and matters enough to track.

At work, git has become non-negotiable. If my team wants to make infrastructure changes, they’d better have a git commit to show for it—otherwise, it’s not happening.

This progression from blind compliance to selective use to universal adoption taught me that the most powerful tools often reveal their true value slowly, and sometimes our biggest limitation isn’t the tool itself but our assumptions about what it’s for.

Your Turn to Experiment

If any of this resonates with you—if you recognize that fear of breaking valuable work, or if you’re intrigued by the idea of fearless experimentation—git might be worth exploring for your own projects.

You don’t need to start with anything ambitious. Pick a project where you already find yourself making backup copies or keeping multiple versions. Try tracking those changes systematically instead of defensively. See if having reliable snapshots changes how boldly you approach improvements.

This isn’t the only way to manage project evolution, and git certainly isn’t the only tool that provides safety nets for changing work. Some people thrive with different approaches entirely. But for those who recognize the paralysis that comes with valuable, fragile projects, git offers one well-tested path toward more confident experimentation.

The yeti’s resurrection ability sounds like fantasy, but the confidence it enables is real. Sometimes the best way to move forward fearlessly is to know you can always step back safely.

Your projects—whatever they are—deserve that kind of freedom.