To provide some insight into why there might be resistance to using personal forks (thanks to
It seems some people might not be aware that personal
forks' branches can be edited by multiple contributors.
There's a checkbox on PRs to allow "maintainers" to edit your PRs even if they're in private fork vs. origin repo.
(I learned this one when contributing to the CRW docs in gitlab too -- it was a new workflow for me a few months ago but the docs team regularly edits each others' MRs.)
So if your workflow involves collaborating on the same PR / pushing changes to someone's PR or topic branch, you can do that in a private branch too. It's only a small change to work outside the origin in your fork, which will keep the origin cleaner.
THAT BEING SAID, I personally have no problem with people using the origin for their topic branches, especially for collaborative work. I was not trying to stifle creativity, make contributing harder, or prevent peer programming.
My concern was simply that these temporary topic branches don't always get cleaned up once merged or abandoned, resulting in a "dirty" project.
It's a bit like if you make a coffee and leave your used mug (merged topic branch) on the counter for someone else to clean up, vs. loading it in the dishwasher when you're done (deleting it). :D
If we all have the diligence to take care of our shared spaces (branches in the origin) then there's no need to police that with GH rules or coded restrictions or administrators. We're all capable of doing our own housekeeping.
So... if we want to continue to use topic branches in the origin, that's fine -- but you're potentially creating work for others (team leads, architects) to clean up your leftovers, if you forget to clean up later.
Hope that clarifies the intent, impact, and workflow concerns with using origin branches vs. personal fork branches.