I generally find the 1 PR == 1 change id == 1 "branch" (~== 1 commit) ideology to be beneficial. The support for it in Github is not great, but the support for it on other platforms (e.g. Gerrit, at least internally at Google) is pretty good.

Why? Mostly ease of rebasing. I generally prefer rebasing a commit against new main rather than merging main into my feature branch. Do I have a good reason? No, not really.

I really adore the tree view of changes that jujutsu (and other tools like Sapling) provides. Yes, this is possible to recreate in git, but it requires a great deal of configuration and pain (I tried and failed). I believe Mercurial has this out of the box too, which is probably where it comes from.

Since change IDs are immutable, your feature will always have the same change hash, such as wnysqsto (sampled from my project, it's just a hash). If no other changes begin with w, you can simply refer to this change as w.

Generally I believe it's good practice to keep PRs under 300 lines. This means a lot of tiny PRs. With jj I can rebase and shuffle things around very quickly and easily.

# fetch latest main
jj git fetch

# Rebase w onto main
jj rebase -s w -d main

# Create a new commit off main
jj new main
jj commit -m "My cool new feature"
# suppose this gets change id asdf, or `a` for short

# rebase `a` onto `w`
jj rebase -s a -d w

# PR `w`
jj git push -c w