Pull requests are created so someone can review the work, make comments, suggestions, make or request edits and then merge the code to master.
In your case the someone is you.
As the sole developer you still should review your own work, refactor it and merge it to master when ready.
One approach I use a lot is to try to 'put on another hat', 'try other personas'. So sit for a short while and place yourself in the situation of: newbie to the group; junior developer; colleague you respected in the past, etc. Try and look at it through their eyes and try to think of simply what could you do to make the change more obvious, better written with even better names that avoid tribal and domain knowledge as much as possible.
So, as you have indicated, you should work in branches when you want to separate out features and changes that aren't ready for master. You can do all that in branches (you don't even need pull requests to manage them if you do the PR tasks anyway, but it may provide useful structure for you).
Also, I will sometimes find that my change isn't working, but rather than the horror of trying to back it out from master, maybe now mixed with other master changes, I can just do it all in a branch which I can then ignore / delete if it starts to go wrong. This is a huge benefit.
So you should work in branches and not commit directly to master until you decide to merge the entire branch.
These are guidelines - and not rules - to follow. I intentionally break them sometimes. For example, yesterday I committed a typo fix to master.
5 years later update: All the above still works well for me. I've recently created many PRs that only I see and approve for myself. The process of having a PR helps me put on that 'different hat' to review my own work.
Frequent things I pick up in my code reviews of my own code:
- commented out code (this is very common)
- print (debug) statements
- missing or poor tests- missing abstractions
- poor naming
- edge cases
- parameter defaults