Should You Use Git on Personal Projects No One Will Ever See?

A photo of a locking mechanism with the title of the article overlaid.

Recently, someone in one of my software-related Discord servers asked if others use git on personal projects. After reading some of the responses, I kept racking my brain for the “right” way to approach the question before coming up short. I ended up settling on the following, but I couldn’t quite get the question out of my head:

I’ll add that there’s basically no downside to versioning your code. “git init” then “git commit” and you have a fully functioning repo. You don’t always have to push to github, and your future self might thank you for tracking changes.

Naturally, I’ve taken to this article to attempt to make a deeper point.

Table of Contents

Why Would Someone Ask This?

Before I answer a question like this, I try to get into the mind of the person asking it. For beginners and even intermediate developers, the amount of tools involved in getting work done can be overwhelming. Sometimes, you just want to write some code and not have to worry about testing, documentation, dependencies, and a slew of other expectations when working on more serious projects, especially in teams.

Therefore, it’s not really surprising to me when someone might feel guilty for skimping out on something like version control in small one-off projects. In fact, my PC has a variety of scripts just floating around without so much as a single commit or test case. Surely, I feel a little guilt when saying that out loud. In fact, I have a couple of scripts that I use to manage my photo library, and I kind of wish I was tracking commits on them.

That said, there’s a reason you would feel guilt for not using git, and it’s not the social pressure. After all, if the script truly is personal, no one is ever going to know it existed and if you versioned it. In fact, outside of people in tech, most folks aren’t going to even know what version control is or does. So, clearly there’s something a bit deeper to that guilt, and that’s what I want to try to unpack.

When you ask something like “should you use git on personal projects no one will ever see?,” what you’re really asking is: should you use git when no one is looking? And, I think this question can extend into a variety of the best practices we preach in tech like “you should probably write unit tests for your code” and “you should probably document your code.” Ultimately, the question becomes: should you care about your development process when no one is looking?

Answering the Question

The answer to just about any question I’ve asked up to this point is yes. You should use git on personal projects no one is going to see. You should use git when no one is looking. And, you should care about your development process when no one is looking.

In general, my mindset on how you should approach your work when no one is looking is built on two key ideas: 1) you should take pride in your work and 2) your future self will thank you.

Take Pride in Your Work

I have long felt that software development is a craft, much like woodworking, cobbling, blacksmithing, and painting. There is something about the way software is put together that requires a nice mix of intuition, style, logic, and experience that can only be described as craftsmanship. And much like a craftsman, I believe you should take pride in your work. In other words, you should follow best practices even when no one is looking.

Unfortunately, it can be a bit challenging to take pride in your work these days. Corporations see software only as a means to an end, so the developers are really only respected for their production, not their craftsmanship. Sadly, that mindset has sort of permeated the field with the rise of coding platforms like LeetCode. Now, corporations can quickly test your ability to produce through a series of esoteric problems; there’s no LeetCode for craftsmanship.

Of course, this has been made worse with the rise of generative AI. Now, your ability to produce code is supposedly supercharged as your craft becomes an afterthought—perhaps even a hindrance to your ability to produce. Why be concerned with craftsmanship when the slop is good enough to keep the money coming?

But again, in the age of LeetCode, generative AI, and whatever comes next: should you still take pride in your craft? I think so. Not only does that give you some sense of meaning or purpose in your life, but it’s a small protest to the status quo. When everyone else is vibe coding and producing slop, you can continue to hone your skills. Is it such a crime to build expertise?

With all that said, I should mention that the term “software craftsmanship” has unfortunately been co-opted and tied to a broader movement in tech (including a literal manifesto), but I think the premise as I’ve presented it here is more than enough to get the point across.

Your Future Self Will Thank You

And if you don’t see the value in taking pride in your work, then you should at least selfishly care about your future. I know this is the argument folks in the repair space like to make to justify hoarding (e.g., “well, I might need that obscure part someday”), but I think it’s a good argument regardless.

See, people sometimes point to using version control as a means of rolling back bad changes, but that’s only half of it. Much like studying history, version control can also help you avoid making the same mistakes again. For instance, you might try to make some changes to a script from a year or two ago. If you don’t have a series of commits documenting your development process, you might end up “repeating history.”

As an example, I mentioned previously that I had a script that I use to organize my photos. That script tries to find the date the photo was taken, so it can be stored in the appropriate folder. The trouble is that the date information can be stored in a lot of different places, and sometimes the simple act of moving a photo can change that metadata. As a result, I look up all the places where the date the photo was taken might be. Then, I usually grab the oldest date, but I make sure to ignore any absurd dates, like the beginning of epoch time.

Every so often, I find that the script messes up a photo or two, and I decide to make some edits. Of course, the script itself isn’t versioned, so I have no idea what I’ve tried in the past. I am certain that I’ve tried the same techniques multiple times to no success, and naturally I’m doomed to repeat this process in the future.

At the same time, I’ve certainly done that thing where I’ve changed the script enough that I can’t rollback any new bugs. So, I have a choice to make: “undo” until I’m back to square one or attempt to fix the bug, which digs me further down the rabbit hole. This is not a situation I would ever be in if I had a clear history of changes (and some testing, obviously).

With that said, even this might not be a compelling argument to you. So, I will appeal again to your pride. Don’t you want to get better at development? Then, you should probably treat everything you do as an opportunity to improve your skills. If that means using git when you’d rather not, I’d say that’s good discipline, and your future self will thank you for it.

Never Deal in Absolutes

Despite my advice in this article, I’m not so much of a purist as to say that you should always work towards perfecting your craft. There are certainly scenarios where swallowing your pride is advantageous, though perhaps ethically dubious. For instance, I bet there are at least a few hundred developers out there writing bad code for job security (and many more achieving that same goal by accident).

Therefore, here’s my advice. If you feel guilty for not using a tool like git, then why not use it? I can only see the upside. For everyone else, live your life, man. I don’t know what to tell you.


Hi all! I felt that article had a nice clean ending, so I’m shoving the usual marketing garbage down here. For instance, if you liked this article, why not check out one of these (after all, I’ve been on an AI hater kick, and this might have been your primer):

Likewise, you can take your support a step further by heading over to my list of ways to grow the site. Otherwise, take care!

Jeremy Grifski

Jeremy grew up in a small town where he enjoyed playing soccer and video games, practicing taekwondo, and trading Pokémon cards. Once out of the nest, he pursued a Bachelors in Computer Engineering with a minor in Game Design. After college, he spent about two years writing software for a major engineering company. Then, he earned a master's in Computer Science and Engineering. Most recently, he earned a PhD in Engineering Education and now works as a Lecturer. In his spare time, Jeremy enjoys spending time with his wife and kid, playing Overwatch 2, Lethal Company, and Baldur's Gate 3, reading manga, watching Penguins hockey, and traveling the world.

Recent Blog Posts