It was after discovering/learning `git bisect`, I started really understanding the value of using Git "properly". Being able to pinpoint in which commit an error was introduced is really invaluable.

I `git cherry-pick` all the time when I graft a PR. Sometimes I drift and start doing something unrelated to a task, and I often want to push it as a separate thing. Cherry picking it into another branch is most often how I achieve this. This does mean that I have to be structured in how I construct commits while I work though. Drafting, crafting, fixing and maintaining releases is however probably the most common use case for cherry-picking. Some commits needs to be cherry-picked for other release lanes.

`git worktree` is a feature I've often heard being raved about. I've not yet been able to use it for myself, in out code bases, but I imagine it being very nice if you have it work for you.

Aside: suggestion to add `git switch` and `git restore` to your repertoire. I'm guessing you use `git checkout` for these commands, but switching branches and resetting the staging area are two _very_ different tasks and making these two different commands is a wise decision. Lessens the likelihood for errors, at least for me.