1. Background
2. Gitting Gud
3. Existing Local Backup Solutions
4. This Backup Solution

Background

Lately I’ve been working on some projects—including a complete reimagining of this very website—and as such I’ve been interacting with Git on a daily basis. At some point I ran into some conflicts (let’s call it infighting) between various code assistants (*glares at Copilot*) and the recurrence of some workspace troubles that I have encountered over the years. So I decided that a backup solution more robust than the *copy appropriate code folders to backup folder* approach I’ve been doing for years was needed.

On a related note, since I pivoted to technical writing full time in 2024; I’ve encountered a lot of folks that have been writing for years but have either been forced into the Docs as Code approach, or just want to get more comfortable with it. I get you, and I think I can help.

Gitting Gud

OK, sorry for the pun, but it’s actually relevant here.

Before I get into the specifics of the backup solution, I wanted to address the elephant in the room: yes, if you’re comfortable with the redundancy that git provides when backing up your [pushed] code, then you don’t need an additional backup solution!

To put that into technical terms, if you’re doing something like this…

git add .
git push origin main

…then you’ve just backed up any tracked files to a remote repository. Sweet!

But. But—and this is where things get messy—there’s a lot that can happen before you push.

I mentioned coding assistants above, and I’ll pick on GitHub Copilot (a tool co-developed by OpenAI and Microsoft subsidiary GitHub) here. Copilot seems to take a different approach to other coding assistants that I’ve tried. I confess I don’t entirely understand the differences, but according to ChatGPT (lol):

“The short version: Copilot operates inside the editor’s text model, while tools like Claude Code and Gemini tend to operate around it. That difference makes Copilot uniquely capable of introducing destructive conflicts when you accept or reject suggestions.”

Furthermore, Copilot can make edits even “before you explicitly accept them” (!).

This alone might be reason enough to look for a local code backup solution, but I’ll list a few more:

• You want to push “meaty” commits that contain a full feature, bugfix, etc. rather than lots of little commits (see also: squashing commits is a pain :p)
• You don’t know what you don’t know, and just want the comfort of being able to manually revert files if something gets borked
• You’re rebasing commits (and not fully comfortable with it)

Existing Local Backup Solutions

It’s worth noting that there are lots of existing backup tools out there. (I, for one, used the free version of FBackup for years). Although I think the propagation of free cloud backup services like Google Drive and Microsoft OneDrive have obviated the need for a lot of folks to run local backups; if you already use a local backup utility then this solution may be overkill.

This Backup Solution

OK, I think we’re finally past the caveats 😸 The particulars of my backup solution (I call it “ReactiveBackup”) can be found at https://github.com/jtasse/ReactiveBackup and its README file.

But here’s a quick primer:

ReactiveBackup allows Windows, MacOS, and Linux users to configure and run code backups for 1 to N repositories on your local machine. You can use the tool to run a quick ad hoc backup, or have it run backups automatically (it’ll look for changes in x configured code folders within the last y number of configured minutes).

I hope you like the solution and find it useful. If you find bugs (I am sure there are bugs—after all this thing was the product of a few vibe coding sessions 😹) please report them at https://github.com/jtasse/ReactiveBackup/issues. Otherwise, you’re welcome to reach out to me with questions/comments.

Thanks!