Git Rebase Simulator

The problem

Rebase is the Git command developers fear most, and the fear is earned. It is usually explained as "moving commits onto a new base". It doesn't move anything. It writes new commits with new ids and leaves the originals in the repository, with nothing pointing at them. Almost every "I lost my work" panic, and its cure, the reflog, comes from that one misunderstanding.

Good visual tools exist, and Learn Git Branching is the best known. I link to it from the site. But the tools I looked at share three gaps. They use fake ids like C1 and C2, so a rebased commit still looks like the same commit. They hide commits that were left behind, so nobody learns how to recover them. And they have no file content, so there are no conflicts, which is exactly where rebase hurts. The simulator is for developers who use Git daily but don't trust rebase, and for people who teach it.

What I built

The simulator works the way Git stores data

I implemented Git's own storage model and let the drawing read from it. Every commit id is calculated from the commit's content, including its parent. So when a rebase gives a commit a new parent, its id changes on screen by itself. Commits are only ever added, never edited or deleted, unless you run cleanup. After every command in every test, a check confirms that nothing that existed before has changed or gone.

Left-behind commits stay on the board

After a rebase or a hard reset, the old commits stay visible, greyed out and with no branch pointing at them. A reflog panel lists every time a branch or HEAD moved, and what moved it. One click creates a branch at a lost commit, which is the same fix you would use in real Git.

Real files make real conflicts

Each commit carries actual file content. When a rebase can't apply cleanly, you get a three-way conflict with Git's own markers, and you continue, skip or abort as in Git. A comparison view runs merge and rebase from the same start, side by side. The histories look different, but the final files are identical, and a test checks that.

I checked it against real Git

A teaching tool that is plausibly wrong would train people to misunderstand rebase with confidence. So I wrote a script that runs the real Git program through nine scenarios, two against a bare repository acting as a remote, and records the results. The tests compare the shape of the history: parents, branch positions and which objects are new. They don't compare commit ids, because real Git mixes in the time and author. The site says so.

Unsupported commands say so by name

The simulator refuses pull on purpose, because pull hides the half of its job that rewrites history. Its error message tells you to use fetch followed by merge or rebase. A few advanced options are refused the same way. A confident wrong answer is the worst thing a teaching tool can give.

Result

The Git Rebase Simulator is live and open source under the MIT licence, in English and Indonesian, and works offline after the first load. It supports 17 Git commands, including interactive rebase and a simulated remote for push, fetch and force-push. Six ready-made scenarios, such as an accidental hard reset or a dangerous force-push, can be shared by link. I built it in about five hours on 5 August 2026, from a written spec.