GitButler argues that Git's branching model imposes unnecessary cognitive overhead — the constant cycle of stashing, switching, and resolving conflicts burns significant engineering time. Their virtual branches model lets multiple branches coexist in a single working directory, automatically sorting changes, eliminating context-switching friction that Git was never designed to handle.
The editorial emphasizes that Chacon co-founded GitHub and wrote 'Pro Git,' the canonical Git reference. When the person who helped make Git the industry standard says the tool has fundamental limitations, the argument carries weight that similar claims from others would not.
The editorial stresses that GitButler isn't a cosmetic layer over git checkout — it implements its own merge engine and diff tooling in Rust, operating directly on Git's object model. The distinction matters because it means GitButler can offer workflows fundamentally impossible within Git's native command set, like dragging individual hunks between simultaneously active branches.
GitButler, the Rust-based version control client founded by Scott Chacon, announced a $17M Series A round. If the name doesn't ring a bell, the resume should: Chacon co-founded GitHub and literally wrote the book on Git — "Pro Git," which remains the canonical reference nearly fifteen years after publication.
The headline — "We've raised $17M to build what comes after Git" — is the kind of statement that only someone with Chacon's credentials can make without getting laughed out of the room. When the person who helped make Git the industry standard says the tool has fundamental limitations, it's worth paying attention.
GitButler is open source, built in Rust using Tauri for the desktop shell (conspicuously not Electron), and has been gaining traction among developers who are tired of the cognitive overhead that Git's branching model imposes on everyday workflows.
### The Virtual Branch Thesis
Git's branching model is powerful but operationally painful. Every developer knows the ritual: you're mid-feature, a bug report comes in, you stash your work, switch branches, fix the bug, commit, switch back, pop the stash, resolve the inevitable conflict, and lose twenty minutes you'll never get back. Multiply that by a team of fifty and you're burning engineering days every sprint on version control choreography.
GitButler's answer is virtual branches — a model where multiple branches coexist in a single working directory simultaneously. Changes are automatically sorted into the appropriate branch as you write them. You can drag individual hunks between branches. There's no switching, no stashing, no context-destroying checkout. It's the workflow Git would have if it were designed for how developers actually work in 2026 rather than how Linux kernel maintainers worked in 2005.
This isn't a cosmetic wrapper around `git checkout`. GitButler implements its own merge engine and diff tooling in Rust, operating on Git's object model but bypassing the CLI entirely. The technical ambition here is significant — they're not building a GUI for Git, they're building a new branching abstraction that happens to be compatible with Git repositories.
### Why Not Just Improve Git?
This is the question that comes up immediately, and it's fair. Git is deeply entrenched. Every CI system, every code review tool, every deployment pipeline assumes Git semantics. The switching cost for version control is astronomical.
Chacon's implicit argument is that you don't replace Git at the protocol level — you replace it at the interaction level. GitButler reads and writes standard Git objects, so your GitHub PRs, your CI pipelines, and your deployment scripts don't care that you used virtual branches to create them. It's a compatibility-first approach: be a better Git client today, become something more tomorrow.
This is strategically shrewd. The graveyard of "Git replacements" is crowded — Fossil, Pijul, Mercurial (effectively), Sapling — all technically interesting, none able to overcome the network effects. GitButler sidesteps the adoption cliff by staying Git-compatible while introducing workflows that Git itself can't support.
### The Rust-and-Tauri Bet
The technology choices are worth noting. Building a desktop dev tool in Rust with Tauri rather than Electron is a statement about performance expectations. Electron apps (VS Code excepted) have earned a reputation for sluggishness, and version control is the kind of operation where a 200ms delay on every diff feels like sandpaper. GitButler's custom Rust implementation of Git operations means they control the entire stack from disk reads to UI rendering.
This also has implications for extensibility. A Rust-native Git library gives GitButler the ability to implement operations that libgit2 doesn't support well — like their virtual branch merge resolution — without being constrained by the upstream library's priorities.
### Should You Try It?
If you're a developer who regularly juggles multiple branches — and who isn't — GitButler is worth a serious look. The virtual branch model genuinely reduces context-switching friction, and because it writes standard Git objects, there's no vendor lock-in risk. Your team doesn't need to adopt it collectively; individual developers can use it alongside teammates running vanilla Git or any other client.
The low-risk adoption path is the most compelling part of the pitch: try it on your personal workflow, and if it doesn't stick, your repository is unchanged.
### The Bigger Signal
The $17M isn't just a bet on GitButler. It's a bet on the thesis that developer tools built in the 2005-2015 era are hitting their UX ceilings even as their protocols remain sound. We're seeing this pattern across the ecosystem: terminal emulators (Warp, Ghostty), build systems (Turborepo, Nx), package managers (uv, Bun), and now version control. The protocol stays, the interface gets rebuilt from scratch — usually in Rust.
For engineering leaders, the question isn't whether to replace Git. It's whether your team's daily friction with Git branching is high enough to justify evaluating a new client. If your developers are spending more than a few minutes per day on branch management overhead, the answer is probably yes.
### What to Watch For
The critical question for GitButler is whether virtual branches can handle the messy reality of large monorepos, complex merge conflicts, and enterprise compliance requirements. The concept is elegant for solo or small-team workflows, but the edge cases multiply fast at scale. Chacon's GitHub experience should inform their roadmap here, but it's still early.
Also worth watching: how AI integration evolves. An intelligent version control client that understands your change patterns could do things Git never could — automatic branch organization, conflict prediction, semantic diff. The $17M likely funds exploration in this direction.
Git isn't going anywhere, and GitButler isn't asking it to. What's happening is more subtle and potentially more impactful: the developer tooling layer is being rebuilt with modern languages, modern UX assumptions, and modern workflows. Chacon betting against the workflow he helped popularize is either the most credible signal in dev tools this year, or a founder narrative that's too neat to be true. The code is open source — you can decide for yourself.
- leads with amount of money raised - mentions a16z - i use git every single day and have no idea what exactly the thing will dothey aren't building something to help you, they're building something to trap you. even if it's free, does things you like, etc., do not use it. their end g
A lot of people seem confused about how they raised the money, but it’s actually a pretty easy VC pitch.- It’s from one of GitHub’s cofounders.- GitHub had a $7.5B exit.- And the story is: AI is completely changing how software gets built, with plenty of proof points already showing up in the billio
I recently switched to Jujutsu (jj) and it made me realize that “what comes after Git” might already exist.It turns out the snapshot model is a perfect fit for AI-assisted development. I can iterate freely without thinking about commits or worrying about saving known-good versions.You can just mess
Installed GitButler to try it out — and realized it installs malicious Git hooks to take over the git commit workflow:* pre-commit — The malicious one. It intercepted every `git commit` attempt and aborted it with that error message, forcing you to use `but commit` instead. Effectively a commit hija
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
> The old model assumed one person, one branch, one terminal, one linear flow. Not only has the problem not been solved well for that old model, it’s now only been compounded with our new AI tools.A bit of a strange thing to say in my book. Git isn't SVN and I think these problems are alread