GitButler

GitButler is a Git client built around the concept of virtual branches — a reimagining of how branching should work in a modern development workflow. Rather than forcing you to commit, stash, or switch branches before starting a new line of work, GitButler lets you maintain multiple virtual branches on top of the same working directory at once, applying them selectively and pushing each independently when ready. The backend is written in Rust using Tauri, giving it native performance with a polished web-based UI. GitButler was co-founded by Scott Chacon, a co-founder of GitHub, and represents a fundamental rethink of the branching mental model rather than just another Git GUI.

Features

• Virtual branches — maintain multiple in-progress branches simultaneously in one working directory; assign individual file changes or hunks to different branches
• No stashing or switching — move freely between lines of work without the context-switching overhead of git stash or git checkout
• Hunk-level assignment — drag individual diff hunks between virtual branches so each branch contains exactly the changes it should
• Branch stacking — stack dependent branches on top of each other and manage the whole series visually
• One-click push — push any virtual branch to a remote and open a pull request without leaving the app
• GitHub integration — view PR status, checks, and comments inline; authenticate via OAuth or SSH keys
• Commit rewriting — amend, squash, and reorder commits through the UI without touching the command line
• Undo history — every operation is reversible; a full operation log lets you step backwards through any mistake
• Tauri / Rust core — the backend that talks to Git is written in Rust for correctness and speed; the frontend is a lightweight web UI bundled natively

Installation

GitButler ships as a native installer for all platforms. There is no cargo install path because the app bundles a web frontend alongside the Rust backend.

# Debian / Ubuntu
# Download the latest .deb from the releases page:
# https://github.com/gitbutlerapp/gitbutler/releases
wget https://github.com/gitbutlerapp/gitbutler/releases/latest/download/gitbutler_amd64.deb
sudo dpkg -i gitbutler_amd64.deb

# Fedora / RHEL
# Download the latest .rpm from the releases page:
# https://github.com/gitbutlerapp/gitbutler/releases
sudo rpm -i gitbutler_amd64.rpm

# macOS
brew install --cask gitbutler

# Arch Linux (AUR)
paru -S gitbutler-bin

A universal Linux AppImage is also available on the releases page for distributions without a native package.

Quick Start

GitButler operates on existing Git repositories. After installation:

1. Open GitButler and click Add local project, then select a repository directory.
2. GitButler reads your existing branches and creates a target branch (typically main or master) — this is the upstream base everything is measured against.
3. Click New virtual branch to create your first virtual branch.
4. Make changes in your editor as normal. Modified files and hunks appear in the Changes panel.
5. Drag hunks to assign them to different virtual branches — one branch for a bug fix, another for a refactor, all in the same working directory.
6. When a virtual branch is ready, click Push to push it to the remote and optionally open a pull request.

# GitButler doesn't replace git — your repo stays a normal git repo.
# You can still use the CLI alongside GitButler:
git log --oneline

# GitButler stores virtual branch metadata in the .git directory,
# not in your working tree, so collaborators are unaffected.

How Virtual Branches Work

Under the hood, GitButler maintains a tree of commits that represent each virtual branch's state. When you assign a hunk to a branch, GitButler rewrites the working tree to reflect which changes belong where. From Git's perspective the working directory always reflects the union of all applied virtual branches — you see all your in-progress changes at once.

When you push a virtual branch, GitButler creates a real remote branch containing only that branch's commits, rebased cleanly onto the target. Your colleagues see ordinary Git branches and can review, comment, and merge them as normal.

# Inspect what GitButler has pushed:
git branch -r | grep gitbutler

# The pushed branches are regular git branches — check one out on another machine:
git fetch origin
git checkout feature/my-virtual-branch

GitButler vs Traditional Git GUIs

Traditional Git GUIs expose Git's branching model as-is — you switch between branches one at a time. GitButler's virtual branch model is most useful when you frequently work on several unrelated changes in parallel and want to ship them in separate, clean pull requests without the overhead of constantly stashing and switching.