A Git client for simultaneous branches on top of your existing workflow

Original Article ↗ Hacker News Discussion ↗

A new GUI Git client, GitButler, introduces “virtual branches” that let developers work on multiple feature branches simultaneously in a single working directory, aiming to simplify rebasing, splitting changes, and testing combinations of work-in-progress branches. Commenters praise the idea and UX—especially compared to existing tools like worktrees, changelists, and stacked‑patch workflows—but raise concerns about interoperability with standard Git commands, the cognitive risk of separating tested states from final commit history, and reliance on proprietary metadata. There is also debate over AI‑assisted features such as auto‑generated branch names and commit messages, which some see as helpful for reducing “fixed some stuff” messages and others view as encouraging low‑quality history.

Virtual branches & core idea

  • Tool introduces “virtual branches” that can be applied simultaneously in one working directory.
  • Goal: make it easy to work on multiple features/bugfixes at once, then split them into clean, reviewable branches/PRs.
  • Internally it uses extra metadata and refs/gitbutler/*, plus an “integration branch” to multiplex/demultiplex changes into normal Git commits/trees.
  • Local workflow can be unorthodox, but final output is standard Git objects and snapshots.

Interoperability with Git & other tools

  • Virtual branches are stored as normal refs under refs/gitbutler/…, so users can base worktrees or other tools on them.
  • Authors stress they try not to touch refs/heads/* and keep the index in a reasonable state.
  • However, using Git’s own branch/commit commands while multiple virtual branches are applied is problematic; some operations become ambiguous (“which branch to commit to?”).
  • Users can switch back to plain branches (e.g., git checkout main) and later return to the tool; raw Git generally still works.
  • Some commenters see “cannot mix with normal branching workflow” or “GUI-only” as a deal-breaker.

Comparison to existing concepts (worktrees, changelists, patch queues, other tools)

  • Compared to git worktree: worktrees give multiple directories; this keeps multiple branches in one directory and can combine them without creating merge commits.
  • Compared to IDE changelists: similar in spirit to grouping changes, but these become real Git commits/branches and can be shared.
  • Some users relate it to ClearCase views/config specs or patch-queue tools (stgit, quilt) and see similar goals with different tradeoffs.
  • Mentioned alongside jj and stacked-git as part of a broader space of “stacked/advanced” workflows.

Usability, UX, and missing features

  • Several users appreciate the visuals, embedded demo videos, and drag‑and‑drop operations (undo, squash, amend).
  • Requests include:
    • Better docs/long-form examples of multi-branch workflows and daily rebasing.
    • Fine-grained hunk splitting and moving hunks between branches beyond the last commit.
    • IDE/editor integrations and Windows support.
    • More explicit mapping of UI actions to underlying Git commands.

AI features & commit metadata

  • Tool offers optional AI-based commit messages and auto branch naming; these are off by default.
  • Some see AI names/messages as helpful placeholders compared to low-quality human messages.
  • Others argue AI commit messages are often semantically wrong (describe “what” not “why”) and risk encouraging bad habits.

Concerns & skepticism

  • Some fear added abstraction will make debugging Git issues harder or encourage risky workflows where inter-branch dependencies go unnoticed.
  • A few consider the whole concept unnecessary versus disciplined use of branches, rebasing, cherry-pick, or scratch branches.
  • One monetization detail—defaulting committer identity to the tool unless changed—was called a “non-starter” by some.