Benefits of using Git (and GitHub) as a solo dev

This post is part of my pre-launch series for my upcoming course Get Really Good at Git launching on May 21. If this post helps you, the course will be a great fit for you, to help you get a much better understanding of Git, reduce your frustrations with it, and figure out the good parts of this incredibly useful tool

Git is an essential tool for teams and groups of people collaborating on the same project, letting people work individually on part of the code that then is merged together to move the project forward.

Maybe less obvious, but still very compelling, is using Git as a solo developer, working on your own projects.

Whenever I am working on some code, I set up Git and start committing my changes.

This has several advantages.

First of all, I think that — even though it’s not the primary use case of Git — this is a great backup strategy.

In case my laptop gets stolen and for some reason I can’t get back my data through my backups, or my backup wasn’t recent enough, I know I have all the code on GitHub, so that part of my work is not lost.

I have to be proactive, committing code often (at least after each work session), but it’s worth it.

Of course the “version control” part, which is Git’s core feature, is a great benefit even if I’m working solo.

In my codebase I might go into a rabbit hole and my code is now in an unstable state and I have to get back to where I was yesterday - Git is perfect for this.

I regularly use branches even if I’m working alone on a project, when I’m in for a big refactoring.

I have a terrible memory, too, so Git serves as a historic log of everything that happened in the codebase.

Have you ever discovered a bug and wondered how much time this bug has been in your codebase? Git can give you this information.

Imagine working on a project for years and years, there’s no way I can remember what I did 4 years ago without having a good commit message that explains what I did (and maybe even why).

In particular a super useful tool I sometimes use when debugging is git bisect, which allows you to go back in time and find a version of the codebase that didn’t have a specific bug, and quickly identify the version that introduced it.

Also, I might do some changes to one of my websites for example, and need to revert the change 1 year later. This is often the case for periodical promotions like Black Friday sales.

Another reason is that many hosting platforms let you connect a Git repository, maybe through GitHub, and when you push a change to GitHub, they deploy a new version of the site.

That’s what happens with most of my sites, hosted on platforms like Netlify, Vercel or Railway (and many more).

This kind of workflow is an absolute winner for me, and this reason alone is enough to justify the use of Git even as a solo developer.

In addition to automated continuous deploying, there are tons of automations we can set up, including running test suites - those can be really helpful even if working without a team, when you have a project that’s in production.

You can also build your own workflows using Git Hooks (and GitHub Actions) that you can set up to “do something” when something specific happens.

Also, the Open Source community is mostly centered around Git and GitHub, and being able to interact with Open Source Git repositories is a good reason on its own to learn Git, because you never know, tomorrow you might need to use a package that is not quite doing what you want but a simple change would allow you to use it, and you might be the one to contribute to that package. Using Git and GitHub.

And who knows, you might also want to release something you created as open source.