Skip to content
Jpshlk.
Flat night scene of a git commit graph where a side branch lifts the old site, drawn as a small house under a protective dome, safely above the ground while a hard-hat builder plants a branch flag below.

2 min read

Back Up Your Site With a Git Branch

rebuildweb developmentgit

On this page

This is part 2 of my rebuild series. Part 1 is the story of the whole project.

Step one of rebuilding my site from scratch was deleting almost everything in it. That’s terrifying. This post is about the one-command safety net that made it not terrifying.

”Isn’t git already a backup?”#

Technically, yes. Git keeps the full history of every file, so nothing committed is ever really gone. But here’s the practical problem: once you delete files and pile new commits on top, finding the old stuff means digging through history with commands you have to look up every time.

A branch fixes that. A branch is just a named pointer to a specific moment in your repo’s history. Point one at your site as it exists today, and the entire old codebase stays one click away on GitHub. Forever, no digging.

The whole backup#

git branch legacy-site origin/main
git push -u origin legacy-site

That’s it. The first line creates a branch called legacy-site pointing at the current state of main (the old site). The second pushes it to GitHub. Nothing about your live site changes; you’ve just planted a flag that says “the old site lives here.”

Now you can delete files on your working branch with total confidence.

Actually using the backup#

Here’s the part I didn’t know before this project. You don’t have to switch branches to look at old code. git show can read any file from any branch directly:

git show legacy-site:src/components/BaseHead.astro

That prints the old BaseHead component to your terminal without touching your working files. During the rebuild we used this constantly. “What props did the old social icons take?” was one git show away, while the new code stayed untouched in the editor.

You can also just browse the branch on GitHub with the branch picker dropdown. Old site, fully intact, read-only.

Branches vs. tags (two-sentence version)#

A tag is like a branch except it’s meant to never move: a permanent label like v1-legacy. A branch can accept new commits; a tag is a snapshot. For a backup, either works; I did both, because they’re free:

git tag v1-legacy origin/main
git push origin v1-legacy

The mindset shift#

The real value here isn’t technical, it’s psychological. Every destructive step in the rebuild (deleting the layouts, the components, the old configs) felt fine, because “undo” was always available. If the rebuild had gone sideways I could have walked away with nothing lost.

If you’re about to do anything drastic to a project: branch first. It costs five seconds and buys unlimited courage. 💪

Thanks for reading and have a good one! 🤙

Comments

Powered by GitHub Discussions. Sign in with GitHub to join in.