I am currently working on a project via a fork of the main repo. I am committing my changes to <fork>/master and then submitting pull requests to <upstream>/master.
I have write permission for <upstream>. Am I correct in thinking that I could make this simpler by deleting my fork and simply creating branches for my work (<upstream>/dev_branch1) and submitting pull requests for those branches? What are the advantages/disadvantages of using a fork instead of branching for a repo to which I have write access?
There is not actually much difference; a branch in a different repository (the fork) is pretty much the same as a separate branch in the upstream repository. It’s just that they are a bit more separated.
A few advantages for using a fork may be to have it more separated, in case you want to be a bit more crazy about your changes. You could see it as another staging area before your changes make it to the “real” project. However, a fork brings in some maintenance requirements too; you have to keep the fork up to date if you want to continue working on the project, and GitHub also gives you all the repository features like issues and another level of pull requests that may make it a bit more complicated.
Especially when you are one of the main contributors, just pushing to feature branches within the upstream repository makes a lot sense. This makes that project the primary and single point people will look at for changes. Other developers can see what you’re working on early (before you submit the pull request) without having to look at your own fork, and may comment on it early. One downside to working directly in the upstream repository would be that you need to be careful that you don’t accidentally push to wrong branches; since it’s not your own project, global rules may apply that require you to take more attention.
As for creating the pull request itself, there is no difference at all. You can create pull requests from a branch of the same project just like you can create pull requests from a fork.