Google's Git Killer Is INSANELY Better
(and it's open source)

​

You saw the title. Bold claim, right?

"Insanely better"?

Than Git?

Git is the foundation of modern software development.

It started back around 20 years ago, when Linus tried to build his first Linux kernel, and had enough of SVN.

So Linus being Linus, he just went ahead and built his own.

But what if the way we've always done version control isn't the only way, or even the best way anymore?

That's the core idea behind Jujutsu (jj) – a Git-compatible alternative, started as a hobby project of a Googler who's now working on it full time, with his colleagues, at Google.

​

​Git is like democracy: it's the worst form of VCS, except for all the others.

Let's be honest: Git, despite its ubiquity, has sharp edges.

We all use it, but who hasn't been stung by the staging area, missing unstaged files, accidentally nuked work with a good reset --hard, or dreaded complex merge conflicts and rebases? (I'm look at you 👀)

You spend mental energy managing branches, carefully crafting commit messages before you make them (and only when you're sure you're done working), and navigating a system that sometimes feels like it requires a degree use safely and effectively.

It's powerful, yes, but often cumbersome.
​Linus himself acknowledged Git's limitations, more than once.

​

The Standard Approach (and its Limits)

Most developers tackle this by learning the core Git commands (add, commit, branch, merge, rebase), maybe using a GUI (god forbid) to abstract some complexity, and developing workflows to minimize risk.

We learn to stage changes, commit often (but not too often, leading to messy histories), and treat rebasing or history rewriting with extreme caution because mistakes can be costly and hard, or impossible to undo.

​

​

Conflicts often bring work to a halt until resolved (remember the last time you rebased, found conflicts, tried to fix, then found some more, and ended up with a good old git rebase --abort ..?

It works, but it's often inefficient and carries inherent friction, not to mention frustration.

​

JJ doesn't just do things better, it completely changes the game

Imagine a version control system that feels less like wrestling with commands and more like smoothly shaping your project.

That's jj.

It keeps Git under the hood (it's fully compatible – you can use jj git clone or jj git init on existing repos) but presents a vastly different user experience.
​

Here’s how jj changes things:

No More Staging Area: Forget git add.

In jj, your working copy is the stage.

​

​
Changes are tracked automatically (hit 'jj st' to see the status).

Ready to commit...? You don't have to be ready!

Wait what?

Yep, in jj, you describe the current state with

If you made some more changes, you don't need to commit again.

You'll just run 'jj desc' again, and update your message... Of the same change you're working on.

​
Want to start something new?

That's it. Your previous change is now recorded.

The change evolves until you create a new one (jj new).

This eliminates the need for fixup commits or complex interactive rebases, not to mention `git commit --amend`.

​

Fearless History Editing and undo-ing changes!

This is huge.

Messed up?

Undo reverts the last operation (not just commit), whether it was a commit, rebase, squash, etc.
Made a mistake by undoing? Just undo again!

Want to combine the change you just made with its parent?

Want to edit an old change deep in the history?

jj automatically and safely rebases descendant changes for you.

This is a good place to stop and talk about the elephant in the room, while jj supports commits, you've read I addressed ongoing changes as, well, changes.
​

jj's Changes vs. Commits:

In jj, a "change" represents your ongoing unit of work.

Unlike a fixed Git commit, a jj change is dynamic – you can modify its code or description (jj describe) multiple times. It only solidifies when you start a new change (jj new).

This is why jj log shows two IDs:

​

Change ID: A stable identifier tracking the lineage of your work, even across amendments or squashes.

Commit ID: The familiar Git-like hash representing an immutable snapshot of the repo state. This changes every time the underlying content or metadata is altered.

This dual system allows jj's flexible workflow (like easy amends and jj undo) while ensuring the underlying history remains a series of concrete, Git-compatible snapshots.

​

Conflicts Don't Block // or as I like to call it: REBASE NEVER FAILS!

When you rebase or merge in jj and conflicts occur, the operation still succeeds.

The conflict is marked (jj log shows it), but you aren't blocked.

You can resolve it later with:

(which has a great interactive tool!) or standard merge tools.

This keeps your workflow moving.

​

A branchless workflow (wait, don't run)

jj treats branches differently.

You don't usually need to name them explicitly.

Want to branch off an older change?

Want to merge two lines of development?

It simplifies the mental model significantly.

​

Putting jj into Action

The best way to grasp jj is to try it.

Install it: On macOS, brew install jj.
On Linux/WSL, you can cargo install jj-cli (it's written in Rust) or check their GitHub (jjvcs/jj) for packages like Nix.

Try it on a new or existing project:

New:

Existing:

​

Basic Workflow (repeating commands seen above):

Check status:

View history:

Describe the current working copy change:

Start a new change (making the previous one permanent):

Want to edit an older change?

Want to go back to the latest change?

​

Start small.

Use it for a personal project.

The initial awkwardness, like grabbing that gamepad instead of a wheel, fades quickly as you realize how much smoother the ride can be.

You might find it hard to go back 😉

Let me know if you give jj a spin!

You might be surprised at how much easier it makes your life.

​
Thank you for reading.
Feel free to reply directly with any question or feedback.
Have a great weekend!