Using Tower's Undo to Reverse Local Git Operations Safely

The outcome you want

You made a commit too early, discarded the wrong file, or finished a rebase you now regret. Instead of digging through git reflog by hand, you want one click — or one keystroke — that puts the repository back exactly where it was before the mistake. Tower's Undo feature does this for most local Git operations, and this guide shows how to use it, where it stops working, and what to do when it can't help.

Prerequisites

• Tower 2.x or later on macOS or Windows, with a repository open in its own window.
• The operation you want to reverse must have been performed inside Tower — actions run in a terminal do not populate Tower's undo stack.
• The operation must be local. Pushes and fetches mutate or read shared remote refs and cannot be undone this way.

How Tower's Undo actually works

Tower keeps a chronological, per-repository undo stack. Every state-changing action you perform in the app — commit, amend, merge, rebase, cherry-pick, discard changes, branch delete, stash apply or drop — records the repository state from just before the action. Pressing Undo resets HEAD and the working tree to that saved state. A matching Redo stack lets you step forward again, until you perform a new action, which clears it.

Two details matter in practice:

• Working-tree actions are snapshotted. If you discard changes to a file, Tower keeps the prior content, so Undo restores your unstaged edits exactly — including untracked files the action removed.
• An interactive rebase is one entry. The whole squash/reword sequence collapses into a single undo step, so one press returns you to the pre-rebase commit instead of stepping through every pick.

The stack survives app restarts while the repository window stays open, but closing the window clears it. Depth is roughly 50 actions in recent builds.

Procedure: reverse a mistaken commit

1. In Tower's toolbar, locate the Undo button (a curved arrow pointing left). Alternatively, press ⌘Z on macOS or Ctrl+Z on Windows.
2. Click it once. Tower resets HEAD to the pre-action state.
3. Check the History view: the unwanted commit should be gone, and any files it contained should reappear as uncommitted changes in the Working Copy view.
4. If you undid one step too far, use the Redo button (or ⌘⇧Z on macOS, Ctrl+Y on Windows) to step forward again.

The same steps work for a completed merge, a finished interactive rebase, a discarded file, or a deleted branch. For a discarded file, right-clicking it and choosing Discard Changes, then pressing Undo, should bring the file back with its prior modifications intact.

Where Undo stops: remote operations

Undo is deliberately unavailable for pushes and fetches. After a push, the Undo button is disabled and its tooltip explains that remote operations cannot be undone. This is correct behavior, not a bug: once a remote accepts your refs, resetting locally does nothing to the shared history.

If you pushed something you need to retract, the recovery path is a local reset followed by a coordinated force-push — but only after confirming with your team that nobody has based work on the pushed commits. Treat that as a communication problem first and a Git problem second.

Fallback when Undo is unavailable

If the stack is empty (you closed the repo window, or the action happened in a terminal), Tower falls back to standard reflog navigation:

1. Open the History view and show the Reflog.
2. Find the entry representing the state you want — reflog records where HEAD has been, even across rebases and resets.
3. Right-click that entry and choose Reset to this commit.

This is the same recovery mechanism as git reset --hard HEAD@{n} on the command line, so it works even for operations Tower never saw.

A decision worth making: confirm before you destroy

Undo is a safety net, not a workflow. In Preferences → General, enable "Confirm destructive actions". This adds a confirmation dialog before discarding changes, hard resets, and branch deletions. The extra click creates an explicit decision point, so you rely on Undo for genuine accidents rather than routine carelessness.

Limitations and gotchas

• Per-window stacks. Opening the same repository in two Tower windows maintains two independent undo stacks. Avoid editing the same repo in parallel windows.
• External actions are invisible. Aborting a rebase from the terminal while Tower is open does not create an undo entry; use the reflog fallback.
• Memory usage. Working-tree snapshots of repositories with many large binary files increase memory consumption. If your repo is several gigabytes, watch Activity Monitor or Task Manager during heavy undo use.
• Hidden defaults are unsupported. Older versions allowed tuning stack size via preference keys such as com.fournova.Tower3.undoStackSize. These are undocumented, may vanish without notice, and should not be scripted against.

Verify it works before you need it

Do a dry run on a scratch branch: make a trivial commit, press Undo, and confirm HEAD moves back and the changes reappear uncommitted. Then discard a modified file, press Undo again, and confirm the edits return. Finally, push a branch and confirm the Undo button disables itself with the explanatory tooltip. Two minutes of rehearsal tells you the feature behaves as expected on your version — which matters, because behavior described here covers Tower 2.x through 10.x and details like stack depth have changed across releases.