The mental model is fascinatingly simple. It is: You have a directed acyclical graph (DAG) of "changes", which are often drawn like this.. Then, you have a small set of commands that operate on that graph, e.g. adding changes, fusing two into one or splitting up one into two, adding nodes that have more than one parents, rebasing single nodes or a series of changes. And changing the content of these nodes in the commit graph is almost always done with the normal source code editor - everything one saves becomes already part of the graph when the next jj command is run.
Jujutsu does not use branches much because you are focused on the nodes in the commit graph. And instead of giving every of them manually a name, they are identified with change IDs. Branches are called "bookmarks", they can be attached to a commit graph node, and are used mostly for collaboration.
And when you push that graph of mutable changes to remote, they become a graph of normal commits that should not be changed under normal circumstances (because they are shared history now).