Branch or tag — which makes a better backup?

For throwaway safety points, a branch is fine and easier to push and delete. Tags are better for states you want to keep permanently (releases, milestones) because they signal 'don't move me'. Either one keeps the commits alive; the difference is convention.

Isn't git reflog already an automatic backup?

Sort of, but it's a fragile one: reflog is local-only, entries expire (90 days by default for reachable history, 30 for unreachable), and it records everything, so finding the right entry under pressure is its own skill. A named branch is deliberate and permanent until you delete it.

Do backup branches clutter the repo?

A little, and that's fine — branches are just 41-byte pointers. Use a consistent prefix like backup/ or savepoint/ so they group together in listings, and prune them once the risky operation has proven itself in production.

Should I push the backup branch?

If the repo is shared or your laptop is the only place the backup would exist — yes, always. A backup that lives only on the machine that just died isn't a backup, it's a memorial.

How to back up a branch before doing something risky

About to rebase, reset, or let an AI agent loose on your repo? Spend thirty seconds on an undo point first. Future you says thanks.

Every git disaster story starts the same way: "I was about to rebase / reset / clean / let the agent refactor it, and I figured it'd be fine." Sometimes it is. The thirty seconds below are for the other times.

The thirty-second version

Before any command that rewrites history or deletes work, drop a bookmark:

git branch backup/before-rebase

That's it. You now have a second pointer at the exact commit your branch is on. Rewrite, reset, rebase to your heart's content — if it goes wrong, the way back is:

git reset --hard backup/before-rebase

This works because a branch in git is nothing more than a movable sticky note pointing at a commit. Your risky operations move (or rewrite) the note called main or feature-x. The note called backup/before-rebase doesn't move, and as long as something points at a commit, git keeps it forever.

If anyone else ever touches this repo — or your laptop is the only copy — push the bookmark too:

git push origin backup/before-rebase

A backup that exists only locally protects you from git mistakes, not from spilled coffee.

"But doesn't reflog do this for me?"

Roughly, yes — git reflog remembers everywhere HEAD has been, and it's saved many careers. As a backup strategy, though, it has three holes: it lives only in your clone, entries expire (30–90 days by default), and in a panic you're spelunking through dozens of cryptic entries hoping to recognize the right one.

Reflog is the smoke detector. A named bookmark is the fire exit with a light over it.

When to bother

Before git rebase (especially -i)
Before git reset --hard to anywhere
Before git clean -fd on a tree with untracked work
Before force-pushing anything
Before handing the repo to a code-generation agent and telling it to "refactor freely"
Before merging something big you can't easily review line-by-line

Notice the pattern: any time the downside is "hours of forensic git surgery," the thirty seconds is worth it.

The git.tools way

One-click save points

Save Point bookmarks the exact state of any commit as a named branch on GitHub — right before you do the risky thing. If it goes wrong, Time Travel restores the bookmark through a reviewed pull request.

Create a save point →

Cleaning up afterwards

Bookmarks are cheap but they pile up. Once the risky change has been running in production long enough that you trust it, delete the backup branch — local and remote — and let the next bookmark take its place. A backup/ or savepoint/ prefix keeps them visually grouped so pruning takes seconds.