GitButler is introducing an entirely new way to work on branches, while still remaining in your existing Git workflows.

There aren't a lot of things that I enjoy more than approaching a problem from first principles. That is, looking at something that we've taken for granted unquestioningly for a long time, breaking it down to what we're fundamentally trying to accomplish and building it back up in a way that solves those problems better, simpler or more elegantly.

When we started GitButler, this was our guiding concept. Look at what Git does for us every day as developers, break it down into what we're really trying to use it for, then rethink how we could solve that fundamental problem in a better way.

We're not just building a new Git client. We're trying to figure out what Git solves for you and do those things better, and our first major target is branching and merging.

You may think to yourself, "Why branching? Branching in Git is great!", and compared to tools that Git replaced, you're very correct. But there are two reasons why branching is the most important thing for us to tackle.

The first is that it is by far the place that most of us spend most of our time. The second is that due to that, it's by far the place where most of us waste time, make mistakes, or lose work in Git.

If we can make branching massively better, then it's the biggest possible impact we can make in everyone's workflows, every day.

Git Branches, Pros and Cons

When we looked at branching in Git, we broke it down into what it's good at and what it's not great at.

Git branching is good at a lot of things, especially when you compare it to tooling that many of us used before Git.

It's insanely good at reintegrating branches multiple times, something that it's predecessors like SVN were notoriously horrible at, which has allowed us to have long lived branches that aren't suicidal to finally merge.

It's very good at quickly experimenting, at creating tiny, inexpensive contexts to try out ideas. It's very good at switching contexts relatively quickly and isolating work effectively. It's very smart and sophisticated in various merging scenarios.

But what is it not good at?

Perhaps this is a question that isn't asked enough. It's better than what came before, but does that mask us from the weaknesses in this approach that we endure every day, just thankful that we're less abused than we previously were?

If you think about it, Git branching isn't actually great at several things that are relevant to the modern developer's workflow.

The big thing is that you can't be on more than one branch at the same time. This means that there are a lot of things that you can't easily do.

You can't fix a discovered bug easily without either switching contexts or entangling it into the context you're currently working on. You can't evaluate a coworkers branch without switching contexts or creating a merge artifact (and thus entangling your branches). You can't easily stash or ignore parts of what you're working on.

To tackle these issues, we've developed a new way to do branching and merging called "virtual branches".

With virtual branches, you can basically have multiple branches that you work on simultaneously. Any changes you make can be dragged visually from one branch to another, committed and continuously worked on without switching branches or creating unneeded dependencies between branches or changes.

You are no longer switching branches, you are able to apply and unapply combinations of branches and direct work to any of them at any time.

We find virtual branches to be a much simpler, more powerful and more natural way to work.

Today we are opening up our private alpha to more users to get early feedback. If you're interested in helping us test out an early preview of our new tool, either join our waiting list, or join us on Discord and ask us for an invite.