In addition to my other comment as you wrote you are not familiar with Git yet, some comparison to these commands. You can be in a commit in JJ, while in Git, you are always outside.

'jj edit' seems to correspond to 'git checkout', '@-' is '@~'. '@+' is not possible in Git, because a commit can have an arbitrary amount of children, Git might not even know about, not sure how JJ does this. @~5 is the 5th ancestor, @^5 is the fifth parent, @{5} is this ref five actions ago. This is the ref-log, which you can look at with 'git reflog' or 'git log --reflog'. 'master@{37.days.ago}' also works.

'jj split': use 'git commit --amend' and unselect changes or 'git reset --soft' to an older version, recommit the first part and then take the original commit on top. A git commit consists of a state, not of a diff so putting some commit on top of another that already contains part of the changes results in splitting the former.

'jj describe': 'git commit --amend'

'whoops, insert commit in the middle': just commit

'jj squash': either 'git reset --soft @~2' then 'git commit -c/C' or 'git reset @~' then 'git commit --amend' or 'git rebase' with squash or fixup. The later is possible from some other commit by using 'git commit --fixup' or even 'git absorb' (I think also exists in JJ).

Working in a detached state is fine, but you might want to add a ref (branch or tag, or something else) when you are finished, otherwise Git will eventually garbage-collect them (defaults to 4 weeks to 90 days depending on how you access the commit). You can push just fine to a remote, just specify the branch, i.e. 'git push origin @:branch'. You can also push to local branches to update them without checking them out with 'git push . @~7:feature/something'. Don't use pull, it is stupid, merge when you want to merge, rebase when you want to rebase, but don't do it implicitly as part of fetch.

Ask, if I glossed over something and shall elaborate.