This confirms was I was thinking. In terms of backup, a private branch is dependent on the dev, while a public branch... well is public, so everyone gets a copy.
Your definition of public and private branch is not so strict in Git. In fact it does not distinguish on this property per se. Let's make an example:
* Imagine SSU is maintained in Git, with a cloud copy on the platform Github. The copy on Github has only one branch, the "master".
* People new to the project clone the Github repo, thereby creating a copy on their machines.
* Dev A creates a "work" branch on his machine, which he never pushes to the Github repo. He just merges his commits into the "master" branch (also on his machine) and pushes those commits to Github.
* Dev B does the same. He also has a "work" branch, but this is nothing like the one of A.
* Up to this point you can say the whole community has 3 branches: 1 "public" master, 1 "private" DevA/work, and 1 "private" DevB/work.
* But Git also allows for devs to share their branches. All they have to do is either to push the commits to the server and pull it from there, or simply exchange them directly. I.e. Dev A wants to show his work to B without commiting it to master yet. So he simply pushes his "work" branch to B, or B can pull the "work" branch into his own repo. The name conflict is resolved automatically by Git by means of prefixing the names with the so-called "remote" name. Let's say B calls the address of A's repo "DevA", then A's "work" branch will be visible in B's repo under the name "DevA/work".
* So now the simple public/private property falls apart. There are only branches that either are visible in a copy or not. Github has only "master", A has "master" and "work", B has "master", "work" and "DevA/work".
What about write access to that "blessed" repo? Is it still limited as SVN?
Write access in SVN is best compared with push access in Git. Whoever hosts the blessed repo can also control who has push and/or pull access.