Parallel branches are the reason to try GitButler
GitButler lets several branches remain active in one working directory. Stacked branches record dependencies between changes, while edits to an earlier commit can be restacked above it. Commits can be moved, split, amended, squashed, or returned to uncommitted changes from the desktop app or the but CLI. An operation timeline records changes and supplies undo actions. That directly addresses the worktree, stash, and interactive-rebase routine many Git users assemble themselves.
The same Rust engine backs the Tauri app and CLI. Release 0.22.1 added branch targeting to more commit commands, individual conflict-resolution commands, and JSON output changes. Forge integration covers GitHub, GitLab, and Bitbucket. Built-in AI can draft branch names, commit messages, and pull-request descriptions, while agent skills expose the workflow to coding tools. This helps when a person and an agent modify the same repository.
Version 0.22.1 has a risky stacked-restore report
An open Linux report describes restoring a stack of 8 branches. According to issue 15573, only the top segment moved back, 7 lower segments became unapplied, and the reporter recovered by editing refs with git update-ref. The issue includes a reproducer and labels its proposed internal cause as a guess. The broken state is documented; the explanation remains unconfirmed.
This report concerns GitButler's main promise. Stacked-branch users should practice recovery on a disposable clone, inspect refs after a large undo, and keep remote branches or another backup boundary. Issue 15573 shows why the timeline cannot be the only recovery plan. Teams that rarely stack changes may get more familiar behavior from Lazygit.
What happened when we ran it
Our sandbox install failed with exit 1 after 9 seconds at commit cab5e6d. We used a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM. The checkout contained 4,670 files, about 599,661 source lines, and occupied 28.6 MB. It was a pnpm monorepo with 13 workspace projects. Our scan found 12 CI workflow files, no Dockerfile, and no tests directory.
The log reported two stopping errors. pnpm said neverBuiltDependencies and onlyBuiltDependencies could not both be present. It also rejected Electron 43.3.0 because Electron required Node 22.12.0 or newer while pnpm reported v20.20.2. Although the image was named lab-node:22, the log records the runtime pnpm used. It did not identify why those settings or that runtime were active.
Installation did not finish, so our run produced no build or test result. The 12 workflow files prove upstream automation exists, but they do not replace a passing result on our box. This checkout did not become runnable in the stated environment, and a contributor has two setup errors to resolve before compilation.
The documented Node floor did not satisfy Electron
The guide says Node 20 or newer, while the root manifest at cab5e6d declared Node 20.11 or newer and pnpm 10.20.0. Our log showed Electron asking for Node 22.12.0. Contributors should follow the stricter version seen by the resolver and check pnpm's built-dependency settings before retrying. That mismatch makes the current source instructions less dependable than their friendly tone suggests.
Desktop development also needs Rust, Tauri libraries, and native build tools. Debian-family systems need WebKitGTK, SSL headers, app-indicator support, SVG libraries, and CMake. macOS needs Xcode command-line tools and CMake. Windows needs MSVC and Perl for OpenSSL. CLI-only work removes the Svelte layer, though vendored Git and OpenSSL still need a C toolchain.
Local Git work does not depend on GitButler Cloud. Forge features require an authenticated GitHub, GitLab, or Bitbucket account. AI assistance can use GitButler's API without a personal key, or your OpenAI, Anthropic, Ollama, or LM Studio setup. Private-repository users should decide which provider receives diff context before enabling generated text.
The license blocks competing use for two years
GitButler uses FSL-1.1-MIT. It permits internal use, study, modification, and redistribution for allowed purposes, while forbidding a commercial product or service that competes with GitButler or related services. Each version converts to MIT on its second publication anniversary. The contribution guide calls the project not strictly open source. Companies building Git tooling need legal review before reusing the code.
Outside contributions require signed commits, and maintainers ask people to discuss work before investing in it. The guide says the Berlin company team drives development and outside work is not central to its process. That candor matters in a 4,670-file codebase where a deep private fork would be expensive to carry.
August activity is high, while desktop reports remain current
GitHub recorded 21,573 stars and a last push on August 26, 2026. It listed 415 open issues and pull requests combined, so that figure is not a bug count. Release 0.22.1 arrived on August 24, and reports were still receiving updates on August 26. The project is active, with users exercising fast-moving branch and conflict behavior.
Windows needs a separate trial. Issue 15556 reports Defender blocking the official 0.22.1 MSI executable and removing shortcuts. Issue 14886 asks for a portable archive because the MSI is awkward without administrator rights. These are individual reports rather than proof of a universal failure, but either can stop adoption in a managed workplace.
GitButler earns a trial when stacked reviews and commit surgery consume real time each week. Start with the packaged client on a clone, test your repeated branch operations, and learn the plain Git recovery route. Choose Git Town for a lighter stacked-branch layer, Lazygit for familiar terminal Git, or Jujutsu for an operation-log model with a new command language.