I’ve been experimenting with the so-called branchless version-control workflows. The idea is that instead of using named branches, you just juggle a bunch of commits on top of the main branch.
Here are a couple of tools implementing the idea - while Sapling and Jujutsu bill themselves as new VCSs, they both work with git repos:
- git-branchless, which builds on top of git
- Sapling (sl), a new VCS published by Meta
- Jujutsu (jj), a new VCS which has some Google backing
git-branchless is the one I’ve used most so far. The others I have only dabbled with.
A central feature of these tools is the “smartlog” which shows the graph of
commits you have on top of the upstream main branch. Sapling’s smartlog output looks like
this - you have three commits on top of main and the @ sign indicates that you’ve checked out the commit with hash 335bb92d2.
$ sl
@ 335bb92d2 3 seconds ago miikka.koskinen
│ fix: fix bug B
│
│ o d5c08952e 21 seconds ago miikka.koskinen
├─╯ feat: implement feature A
│
o 5ca31cccb 69 seconds ago miikka.koskinen
refactor: refactor the code base
This kind of situation happens to me regularly: I’ve made a refactoring (or a bug fix) in one branch and I want to start another branch on top of it. But what happens if you spot a mistake in the refactoring and want to edit in?
In plain git, you’d probably do a fixup! commit on top of either of your
branches - the one with the feature A or the bug fix B - and git rebase -i it
into the refactoring commit. Then you’d rebase the other branch on top of the
new refactoring commit.
In Sapling, you’d switch to the refactoring commit with sl previous or sl goto and use sl amend to edit it. This automatically rebases the descendant
commits on top of the new commit.
This is especially nice if you like to use stacked PRs. I’ve lately used them a lot since I’ve worked on big changes that would be difficult to review at once. I’ve yet to try any of the tools’ GitHub integration - I’ve just manually managed the PRs - but the tools make it easier to deal with the code review fixes to the root PR.
Another thing it’s good for is creating experimental commits - having the smartlog and not having to name your branches removes a lot of friction from branching out for experiments.
All of this is possible with plain git, but the new tools make it more convenient and less error-prone.