I worked on a Tensorflow feature in 2018. There was no branching involved. Fork the main repo, build the feature on your child repo, make sure all unit tests pass and then send a pull request to the main/master of the parent repo. Typically someone reviews the code, you incorporate code review comments, pass all unit tests, CI-CD pass, PR approved. That's it. Your code is in the next production cycle.
So yes, you work locally on a fork of the repo but not the main/master repo. I'd surprised if all devs have access to push to main/master.
I think having branches leads to a lot of merging issues. Because technically, the branch will then be used by multiple devs. So it's like dealing with multiple masters, kind of.
Personally, I prefer the TF approach. Oh I forgot to mention, the release tags are branches I think, perhaps read only branches.
This is just branching, except your branch is in a different repo. You just call the branch downstream/master and your local master, instead of the more common origin/yourbranch and your local yourbranch.
For the rest the merging issues are identical. You can still have a merge conflict between downstream/master and origin/master if someone merged something conflicting into origin/master since the fork happened.
What you say is certainly true, but there are still meaningful differences: named branches give you the option to push them before merging as an informal remote backup (good) switch to a different named branch (neutral) and let the old one grow stale (very bad)
How would you describe the difference between branches and forks? Functionally I can create a new branch, do my changes, get tests passing and PR from there, or I can fork master, do my changes, get tests passing and PR.
Yes technically this is a branch, but like a frictionless branch. You don't have to name a branch for instance. You don't have to worry about branch deletion, even though now this is all automated.
Ah right, generally I quite like having branch names because I can name the brach aligned to the jira ticket that it's associated with, I'm not a big fan of jira, but atleast it documents the feature request etc. And also you can track multiple different features in flight at once (I know it's not ideal, but sometimes you're doing several different things that need to be merged in order etc)
So yes, you work locally on a fork of the repo but not the main/master repo. I'd surprised if all devs have access to push to main/master.
I think having branches leads to a lot of merging issues. Because technically, the branch will then be used by multiple devs. So it's like dealing with multiple masters, kind of.
Personally, I prefer the TF approach. Oh I forgot to mention, the release tags are branches I think, perhaps read only branches.