I found this other question here that seeks general understanding of the SourceTree history graph. There was a start of an answer, but I want to take it further. I'd love to get pointers to documentation or other helpful information. However, I will ask a few specific questions about this particular case.
For the given Git repository, I have 8 branches local and I have highlighted an additional branch that is only remote.
Of course, any pointers to further documentation would be greatly appreciated.
First of all, may I suggest you get a good book or online training course on Git and study up? Getting these concepts straightened out will serve you well if you are going to be using Git.
The commit, not the branch is the fundamental unit of work in Git. Everything depends on the commit. A branch is nothing more than a pointer to a specific commit. This is true even for master and HEAD. I think you might be confusing these two concepts which leads to your questions.
Hope that helps.
Commits that do not have any connection to any branch or tag label will not show up in the Sourcetree ui or git log, so deleting a branch can make 9,000 commits just disappear.
If you had recently checked out the branch before you deleted then a reference to it will be shown in the git reflog command list and you can then create a new branch or tag from the commit hash shown there.
The graph was very obviously designed by a coder. If it had been designed by a UI/UX Engineer, it would've had much more utility, I think.
A graph is a visual representation, a metaphor, if you will, abstracting esoteric information such as statistics or formulas or, in this case, relationships into an image everyone can understand. A metaphor should be readily recognizable at a glance, it should have a representation that a person can recognize. The mere fact that this graph spurs so many questions and requires such repeated and meticulous explanation makes it a bad metaphor, a bad visual representation, and therefore a bad graph.