DEV Community

ferchichibaha7
ferchichibaha7

Posted on

I wanted Git to show me what would happen before changing history, so I built it

#showdev #git #linux #productivity

I use Git every day, but one thing has always bothered me:

when you do something that changes history, a lot of Git tools still basically ask you to understand the command first and trust that the result is what you expected.

I wanted something more visual.

So while building RepoBeam, I added a before/after preview for operations like going back to an older commit.

Instead of clicking the action and hoping I understood it correctly, RepoBeam first shows me what the repository will look like afterwards.

RepoBeam showing a Before and After commit-history preview for a “Back to this commit” operation, so the user can see exactly how the Git history will change before confirming.

For example, when going back to a commit I can choose whether I want to:

  • restore the files as normal unstaged changes
  • restore them already staged
  • create a new restore commit when rewriting published history would be unsafe

And RepoBeam shows the expected history before I confirm anything.

The idea is simple:

show me what Git is going to do before it does it.

RepoBeam actually started for a different reason.

I used Fork for a long time on Windows. When I started working more on Linux, I tried GitKraken, Sublime Merge, SmartGit, GitButler and a bunch of smaller clients, but I never found one that really felt like the Git GUI I wanted to use every day.

So I started building my own.

Over time it turned into a full Git client with:

  • local changes and staging
  • split/unified diffs
  • commit history and graph
  • branches and remotes
  • stashes
  • guided conflict resolution
  • before/after Git previews
  • Coding Sessions

Coding Sessions

This is another part I use a lot now.

When I start working with Codex or Claude, I start a Coding Session in RepoBeam first.

RepoBeam then organizes everything that changes during that session.

I can review the files afterwards, undo one change, bring it back, keep the rest, or undo the entire session.

It does not replace Git or create some separate version-control system. It works with normal Git repositories.

RepoBeam currently runs on Linux and Windows.

Linux builds are available as:

  • .deb
  • AppImage
  • Snap

Private repositories work, no RepoBeam account is required, and the app is free to use including for work.

👉 https://repobeam.com

RepoBeam’s “Back to this commit” preview showing three safe restore options: restore as unstaged changes, restore staged, or create a restore commit while keeping published history intact.

RepoBeam’s guided conflict resolver showing Local and Server versions side by side, with options to keep Local, keep Server, keep both, or manually edit the final result before continuing the merge.

I released 1.8.3 this week and this is the first time I'm seriously putting RepoBeam in front of developers I don't know.

The thing I'm most curious about:

Would a before/after preview like this actually make you more comfortable with Git history operations, or do you prefer seeing the underlying Git command directly?

Top comments (0)