In one sense, Git does not have unnamed branches at all. In another sense, it has an infinite number of unnamed branches. Either way it makes little sense to attempt to display all of them1—and a GitHub network graph doesn't. That's not what a GitHub network graph is.
This is what a GitHub network graph is. It attempts (not entirely successfully, in my opinion :-) ) to display the union of multiple related (by GitHub-fork, I presume) repositories. Thus, what you are seeing is not necessarily anything in your own repositories, but rather across several different repositories, maybe including some of your own, but maybe literally everything is in several other repositories entirely. It might be in your repository, but it might not be. There is not enough information in your existing question to diagnose this
Since Git largely works by adding new commits (while keeping every old commit, through what Git calls references), most things you do will simply add more commits, and perhaps even more lines, to your network graph. ElpieKay's answer to your linked question works by copying commits, which would—and does—add another line, but making sure that the first copied commit has a link back to some existing commit (that's the --onto target of the rebase) and then removing the name that Git used to find the original chain of commits (that's the final step of git rebase itself).
In other words, this (at least conceptually—ElpieKay's answer is specific to one particular situation, ending in a merge commit, that I'm not drawing here) takes:
o--o--o--o <-- main-branch
*--*--* <-- side-branch
and first adds a copy of the bottom row, but with a link back to the top:
o--o--o--o <-- main-branch
\
*--*--* *--*--* <-- HEAD
(I omitted the side-branch label partly to save space, and partly because it sits "under" the copied commits: it still points to the last of the original three commits, though.) Once the copying is done, we "forget" the original three by changing just the one branch label, giving:
o--o--o--o <-- main-branch
\
*--*--* <-- side-branch
The three original commits are forgotten precisely because they no longer have a name, side-branch, pointing to their tip (latest) commit.
One can accomplish this kind of thing with two different Git commands, which have different aims:
git rebase copies some (usually small and simple) set of commits, preferably a simple linear chain, to a new set of commits, also changing the stored snapshot for each copied commit. This is essentially equivalent to doing a series of git cherry-picks on each to-be-copied commit. Then, as we just saw, it moves the branch label so that instead of pointing to the last of the pre-copy commits, it points to the last of the post-copy commits.
git filter-branch copies an arbitrary set of commits, including merges if you like, to a new set. During this copying, each extracted commit snapshot is modified according to / using arbitrary filtering of your choice. This may include omitting some commits, creating new commits, changing the parent linkages of commits, and/or making arbitrary changes to the snapshot. This is therefore much more flexible than rebase, but also much much more difficult to use (and not well suited to the kind of source-tree modification rebase is specifically designed for, either).
Whether any of this will help depends on what GitHub is showing you. Because a network graph is not limited to your repository, there is no guarantee that doing anything within your repository will improve anything you see.
1Every commit can be treated as an anonymous branch, or perhaps even an infinite number of anonymous branches (though the latter is not useful, while the former sometimes is).
One time when it does make sense to show an anonymous branch is when looking at a repository with a "detached HEAD". This is because a detached HEAD literally means that the name HEAD resolves to one specific commit, making that one specific commit act like a branch-tip commit. In effect, HEAD is the name of this branch. But HEAD is supposed to move, or be "re-attached". (Your HEAD is there to move you around.) As soon as you move it, the commit stops being the tip of that anonymous branch.
In the steps shown above for rebase, I show HEAD pointing to the copied tip commit. That is in fact how Git does the rebase, using HEAD as the tip of an anonymous branch. The last step, moving the original branch's name, cements the copies into place permanently (permanent, that is, until you rebase again, or delete the name entirely).
