More branches means less time in a broken state, but more time testing independent versions
You can code and test independently.
That means, unrelated changes from someone else’s branch aren’t going to break yours.
You have to code and test independently.
That means, you eventually have to merge the different changes together, fix all the conflicts and retest everything to make sure there’s no regressions.
If you have many branches, you don’t necessarily have to retest after merging each one, but if you don’t, you won’t be sure which branch caused the breakage.
This is the where everything ends up. Not named after a quarter or other time period because it goes on forever. The vast majority of development, building and testing happens here.
A feature branch created from master and merged back to master when complete.
The branch for a particular release. Created when devs begin work on the following release (in this case, release/2020.1). In other words, when preparing for a release some devs begin working on the following release features, they would create the branch for the current release so that their following-release changes aren’t on it (they’re on master).
With fewer branches, there is a higher velocity at the tip, and higher chance the tips of those branches will be broken at any given time. It’s important to spread the knowledge of test results so that devs and testers don’t try to work with bad builds, as it’s more likely that the best version to build off of is NOT the tip of master.
That can be done with CI and git tagging, although it also helps if results of manual testing are added to tags.