Upgrade your VCS to Upgrade your Agentic Workflow

If you haven’t played with some VCS tools that enable rebasing workflows, they can be extremely powerful. The case for using such a tool is in managing multiple working copies simultaneously. Previously, I think this only mattered for those that worked in a high velocity team. I was on the receiving end of some very distasteful comments about my use of git worktrees. While I disagree with how they approached the initial conversation, I don’t disagree with their position. From their perspective, how I used git worktrees was probably a very stupid way for them to be using them. It’s all about circumstance.

My workflow was tuned for being able to context switch. Most people want to avoid doing that, but I needed to be able to jump between projects, changesets, and tasks in a moments notice. At the time, we were working on go-to-market launches for multiple products.

In the post-agentic era, I think circumstances have very much changed. In fact, I believe they’ve changed so much so that context switching is becoming the core UX of product design (e.g. Clad Labs in YC’s Fall 2025 batch).

We’re seeing many agentic workflows leverage worktrees as a way of isolating sessions. It’s a very good way of doing things. But, I think there is merit to using rebasing workflows that are built into some of the newer VCS clients.

I will start with the client I recommend to most people: GitButler. To call out why I recommend it, parallel and stack branches. This type of rebasing workflow does something which is missing from traditional git — it allows the commits to be treated differently during development and presentation (by presentation, I mean anytime the commits become visible to someone else). To put this more plainly, it’s very easy to reorganize your changes later. Tools like GitButler treat the commit graph as mutable until it’s been pushed remotely, which makes it so much easier to:

Test multiple in-progress changes for compatibility Create stacked PRs — useful for preserving atomicity of large changesets Reorder your commits to optimize them for PR review Keep in mind the importance of the “immutable once pushed” rule which mitigates all major issues caused by treating your commit graph like modeling clay.

As I stated above, I’m not using GitButler. Instead, I’m using Jujutsu. Why I don’t recommend jujutsu is the steeper learning curve, and lack of solid GUI apps. Jujutsu has its own changesets and change IDs which are separate to commit IDs.

At first, having this second layer dimension of changes to manage seems more challenging, but in practice it gives me way more control over how I prepare and present my commits for review. Jujutsu changesets are designed for mutation, and it’s rare that git commits actually need to be operated directly on.

To conclude, I believe there is merit to using VCS tools which separate how commits are treated during “development” and “presentation” phases. Worktrees are just the surface level representation of parallelization during development, but there is so much room for workflow improvement in this space.

If you want to get your toes wet, I encourage you to look at GitButler. If you’re will to put in some time to learn a tool that gives you a simpler, more controlled experience, then most certainly take some time to learn Jujutsu.