gitbutlerapp/gitbutler

Worth trying if Git branch juggling has become the slow part of your day and you want both a desktop app and a CLI backed by the same engine. It still writes ordinary Git repositories, so you are not moving your project to a new host.

The problem

You start on one task, discover a second change is needed, and end up stashing, switching branches, or hand-crafting an interactive rebase. Mid-review feedback then means amending a commit that later commits depend on, which turns into a chain of conflict resolution before you can push. GitButler changes where that work happens: you organize changes into branches visible in a sidebar, edit or move commits directly, and the tool restacks the dependent work. The result is that routine branch splitting and commit cleanup become a few clicks or but commands rather than a rebase session.

What's different

The central mechanism is parallel branches. Instead of one checked-out working tree, the app lets you keep work for several branches at once, which removes most of the branch-switching and stashing loop. Stacked branches sit on top of each other, and amending a lower commit triggers automatic restacking of the ones above it. Conflicts are treated as a first-class state: according to the documentation, rebases always succeed, and commits can be marked conflicted and resolved later, in any order, rather than blocking the whole operation.

That makes the tool feel less like a prettier git status and more like a different way of arranging work before it becomes history. Dragging commits or using CLI commands handles uncommit, reword, amend, move, split and squash, with no interactive rebase required. An undo timeline records operations so you can undo or revert them from the GUI or the operations log in the CLI. The obvious trade-off is conceptual: you are adopting GitButler's model and terminology, so teammates still using plain Git will not see the same mental picture, and anyone who prefers raw index manipulation has to learn where those actions now live.

Forge integration is built in for GitHub, GitLab and Bitbucket, letting you open and update pull requests and see CI statuses without another tool. AI features are optional handlers for commit messages, branch names and PR descriptions, plus installable hooks and skills for agent systems, so they do not change the underlying Git data. The README positions the CLI and GUI as the same Rust backend, which matters if you want consistent behavior between terminal and desktop.

Who should try it

A good fit is a developer who regularly maintains two or three related changes on the same repository and wants to split, reorder or amend them before review without rehearsing rebase commands. It is also reasonable for someone who wants a single client for both local branch work and GitHub/GitLab pull requests. A poor fit is a team that requires every contributor to use only standard Git tooling with identical commands, because the branch model is GitButler-specific even though the repository remains Git. Someone whose workflow is mostly single-branch, commit-and-push would gain little from the extra organization layer.

Requirements and limitations

You need a desktop app installation for the GUI, with downloads linked from the project site downloads page, or the but CLI if you prefer the terminal. Both run against an existing Git repository, and the project describes it as a drop-in interface rather than a new repository format. Configuration lives in the project documentation, so the practical setup cost is reading the branch and conflict model before reorganizing real work.

Ongoing care is mostly about the branch model and forge connection. Forge integrations require authenticating to GitHub, GitLab or Bitbucket, and the AI helpers are optional rather than required for normal use. The undo timeline logs operations for reversal, but that is a workflow aid, not a substitute for understanding what the restacking did before sharing branches with collaborators. The license is Fair Source, with restrictions on building a competitor and a conversion to MIT after two years, which matters if you plan to redistribute or embed the code.

HotRepo's take

HotRepo's only dated observation is 2026-10-25, when the project appeared on the daily board with 21,849 stars and a gain of 8 that day; that single snapshot is not enough to judge whether interest is rising, fading or sustained. The more useful question is whether the stacked and parallel-branch model matches how you already work. Read the branch management documentation and the conflict behavior notes before deciding, and check that the CLI and your team's Git expectations line up.