Do you not use a fork as your origin, separate from the production upstream repo? I’ll push to my fork’s main branch for small or urgent changes that will definitely be merged before anything else I’m working on.
I’d fork it if it’s for a repo that is of value for me but either gets frequent major updates I might not want or hasn’t been updated for a couple years and looks like it might be abandoned.
If it’s a private repo I don’t worry too much about forking. Ideally branches should be getting cleaned up as they get merged anyway. I don’t see a great advantage in every developer having a fork rather than just having feature/bug branches that PR for merging to main, and honestly it makes it a bit painful to cherry-pick patches from other dev branches.
Do you not use a fork as your origin, separate from the production upstream repo? I’ll push to my fork’s main branch for small or urgent changes that will definitely be merged before anything else I’m working on.
I’d fork it if it’s for a repo that is of value for me but either gets frequent major updates I might not want or hasn’t been updated for a couple years and looks like it might be abandoned.
If it’s a private repo I don’t worry too much about forking. Ideally branches should be getting cleaned up as they get merged anyway. I don’t see a great advantage in every developer having a fork rather than just having feature/bug branches that PR for merging to main, and honestly it makes it a bit painful to cherry-pick patches from other dev branches.