The answer is in Sami Kuhmonen's comment:
I assume the list is sorted alphabetically and doesn’t show anything about how the branches relate to each other.
It's worth adding, however, that there's something else important to know here: Git branches do not have any inherent relationships. There is no such thing as the parent branch of some other branch.
What makes this confusing is that commits do have parent/child relationships, and in one sense, branches are made up of commits. So it seems like branches should also have them. The problem is that when we say branches right here, we mean the branch names, like master and develop. These names are merely user-changeable names that Git provides for us to keep track of one single commit. That one single commit that each branch name remembers is called the tip of the branch:
A <-B <-C <--master
Each actual commit has some big ugly hash ID as its real name, and those are impossible for humans to work with, so we have the name master to remember the hash ID of commit C. Commit C remembers the hash ID of its parent B, and B remembers the hash ID of its parent A. (A is the first commit ever made in this tiny three-commit repository, so it has no parent and the action stops here: since it's first, that's the end of history, in Git's backwards-looking fashion.)
To make a new commit, Git writes out the new commit with its new unique hash ID—let's just call it D—and then updates the name master to store D's hash ID. D itself contains C's hash ID, so that Git can find C from D:
A--B--C--D <-- master
Once a commit is made, it can never be changed (at all—changing anything gives you a new commit, with a new unique hash ID, so the old commit has not changed!). We know the internal arrows always point backwards, so there's no need to draw those. When we make a new branch name, however, we end up with two names pointing to the same commit:
A--B--C <-- master, develop (HEAD)
Now we need to attach HEAD to a branch name, so that we know which one we're on! If we make commit D now, the branch name that moves is develop:
A--B--C <-- master
\
D <-- develop (HEAD)
But we can use git reset to move branch names around at any time. For instance, if we don't like D after all, and want to have develop start from B, we can git reset it and make things look like this:
A--B <-- develop (HEAD)
\
C <-- master
\
D [abandoned, will go away in about a month]
If we now make a new commit E, the parent of E will be B, and the visible part will look like this:
A--B--E <-- develop (HEAD)
\
C <-- master
(Commit D has no way to find it—it is unreachable in Git terms—so we can't see it by normal means.)
Conclusion
Keep in mind that each branch name is just a pointer, pointing to one (1) commit, as in the drawings above. Git uses the commits to find their parents, following the chain from "where the name points" backwards through history. But you will find that when people talk about "a branch" in Git, they often don't mean the name, but rather the commits reached by starting at the name and moving backwards. You have to figure out from context whether someone means "the name"" or "the set of commits". For more about this, see What exactly do we mean by "branch"?
