1. Always rebase (feature branches on top of master)
2. That depends, with Git what usually ended up happening was let commits pile up, then when I’m about to merge it to master squash them into logical units. With jj I often just squash as I go since it’s way faster than in git. Look at this branch for example, you can see exactly when I switched to jj (though this entire history is a mess which I’ll still have to untangle before merging)

The killer feature for me is the mega-merge, which is a great workflow that is very difficult if not impossible to recreate in Git which allows you to work on many feature branches at once while keeping them independent. It’s basically a merge commit which you have checked out which has all your feature branches as a parent, and jj makes it trivial to manage this. This is usually how I want to work and with Git what ends up happening if I want to do that is I will add a new feature to an existing feature branch that doesn’t really belong there, but this obviously makes it very easy to write code which depends on the incomplete feature that came first and then becomes very hard to separate if you want to merge the second feature before the first.

This has also essentially saved me from what I did before with Git, which is having way too many work trees (still, shoutout to git worktree here), one for each branch.

Here’s the log from one of my repos that I use the mega-merge with right now: https://paste.gentoo.zip/JRxJDhiQ and the corresponding log on GitHub for the top branch; the log, which I’ve configured here to show the changes that are in my fork but not in the upstream fork, actually shows three main branches (master, nixos-unstable, nixos-24.11). You can see most of the 6 branches that master merges actually have a corresponding remote branch (shown between the date and the commit hash) because they have or had PRs open. Changing anything about this graph (rebasing it on top of new master@upstream, inserting a change somewhere, deleting/modifying an existing change, etc.) will rebase every dependent change, that is, the ones that have the modified one as a parent (!!!) on whatever changed and also update branch pointers, so when I push the next time, for example after a rebase, it will have updated all those branches for me and I don’t have to go through fixing each one. Especially the latter I think is not possible with Git, a rebase operation will only affect the current branch. I have no idea how Git deals with rebasing merge commits, I think I’ve tried once and it became a mess and I haven’t touched rebasing merge commits since.

Honorable mentions include

• conflicts do not block operation, you can resolve them whenever you want to and until then any operation will work, they will just show up with a conflict symbol in the log until you fix them
• branchless workflow: you can just start creating changes off any commit without having to set up a branch first, and they will all show up in the log, which shows you by default all of your local changes that aren’t pushed yet, regardless of which branch (or none at all) they are on
• revsets, a great way to select a set of changes using an expression (this was apparently stolen from Mercurial). For example, I might want to list all of the commits I made that start with “foo:”. This is easy to do with revsets: jj log -r 'mine() & description(glob:"foo:*")'.You can also use this to select a set of commits to be squashed, rebased, deleted, or whatever.