TL;DR
Run git remote and see if you have remotes named remote and bridgent. (Use git remote -v to see the URLs associated with each remote.)
If you don't want to have a remote named remote, use git remote remove remote to remove it. This will remove all of its remote-tracking names too. Repeat for bridgent if / as desired.
If you do want to keep these remotes, but prune any remote-tracking names associated with those remotes, run:
git fetch remote --prune
and/or:
git fetch bridgent --prune
You can also run:
git fetch --all --prune
(or git fetch -a -p for short). The --all means contact all remotes. Or, you can use git remote update --prune; git remote update defaults to fetching from all remotes. The default for git fetch is generally just to call up, and hence update, origin.1
1Technically, the default for git fetch is to call up the remote based on the upstream of the current branch, but if that's not set, it uses origin. Most Git repositories tend to have only one remote, named origin, so this works well. Your Git repository has three remotes, so it does not.
The defaults for git remote update are particularly complicated; see its documentation for details. This seems to be designed for larger mirror sites like one I used to run for a medium-size corporate setup.
Long
Let me quote this part for emphasis, as it were:
remotes/origin/master
remotes/remote/master
remotes/remote/carousel
remotes/bridgent/animate
[snip]
If we take out the remotes/ part from each line, we get:
origin/master
remote/master
remote/carousel
bridgent/animate
bridgent/enlarged-hover
bridgent/master
[snip]
If we further remove the part from the first remaining / onward, and eliminate duplicates, we get this list:
origin
remote
bridgent
This is a list of remotes.
If you run git remote, you should see this same list of names. (If you don't, we have a somewhat different problem to solve than the one I think you are running into.)
Now:
Here is a list of some remote branches on my GitHub repo:
Technically, these are not on your GitHub repository. These are on (or in) your local repository, on your laptop or desktop computer. There is another, different, repository over on GitHub; that one is your GitHub repository.
Remotes and remote-tracking names
Remember that Git is a distributed version control system. As such, there are usually two, or three, or ten or maybe even millions of repositories. Each repository has its own branch names. What all the clones of some repository share is not branches but rather commits. The commits are what get shared. The branch names just help each repository remember its commits. Each commit has a unique hash ID, which is the same in every repository. A repository either does have that commit, which then has that hash ID; or it doesn't have that commit, and doesn't have that hash ID.
When you have your Git call up the other Git over on GitHub, your Git asks them about their commits. They will say, e.g., I have my master as commit a123456... Your Git checks: do I have a123456...? If you do have it, your Git says OK, I already have that one and you don't need to get it. If you don't have it, your Git says Ah, please give me a123456... and their Git now offers the parent commit of that commit. Your Git checks to see if you have that commit. If not, your Git asks for the parent of a123456... and they offer that commit's parent—a123456...'s grandparent—and your Git checks that hash ID, and so on.
In the end, your Git gets, from their Git, all the commits that they have on their master, that your Git does not have at all. So now you have all of your commits plus all of their commits. Your master might well be this a123456... commit. Or, your master might be some other commit. Whatever the case is, your Git now creates a new name, or updates an existing one, to remember their master.
Your Git's memory of their Git's branch names are your remote-tracking names for this particular "other Git". This other Git over on GitHub has a URL; the remote name origin stores this URL. But what if you have more than one "other Git"?
Your Git can call up a different Git repository, perhaps under the name bridgent. This remote name, bridgent, stores a URL. That's how your Git will call up this other Git. When your Git calls up this other Git, they will say things like: I have a branch named animate and a branch named enlarged-hover and a branch named master. My animate is commit b789abc..., my enlarged-hover is commit fedcba9..., my master is ...
Your Git will obtain from the bridgent Git any commits that it has, that you don't. Then your Git will create or update your bridgent/* names. These hold the hash IDs your Git got from the Git whose URL your Git has stored under the name bridgent.
So, since you have origin and remote and bridgent, this means your Git has recorded three separate remotes. Each remote stores a URL; at that URL, some Git answers when you call its number. That Git has a list of branch names. Each branch name identifies some particular commit, by hash ID. Your Git makes sure it has those commits too, and then creates or updates remote-tracking names for each of these other Git repositories.
The remote-tracking names for the Git your Git calls origin are listed under origin/*. The remote-tracking names for the Git your Git calls remote are listed under remote/*. The remote-tracking names for the Git your Git calls bridgent are listed under bridgent/*. That's how your Git keeps all this stuff straight.
But git branch -a prints remotes/origin/master etc
If you use:
git branch
your Git lists your branch names. These come out as master, develop, and so on.
If you use:
git branch -r
your Git lists your remote-tracking names. These come out as origin/master, bridgent/animate, and so on.
Both sets of names are shortened. The actual full name of your master is refs/heads/master. The actual full name of origin/master is refs/remotes/origin/master. The branch names have refs/heads/ stripped off, and the remote-tracking names have refs/remotes/ stripped off.
Putting those prefixes back on guarantees that the names can't collide. If, for some strange reason, you create your own local branch named origin/master, its actual full name will be refs/heads/origin/master. Your remote-tracking origin/master is really refs/remotes/origin/master. Obviously, these two names are different, because of the different prefix parts. Since Git uses the full names internally, Git won't get confused ... but since Git, and you, see the shortened names, you might get confused. Don't create a local branch named origin/master!2
For whatever reason, though, git branch -a only strips the refs/ part when listing remote-tracking names. So git branch -a showed you remotes/origin/master for origin/master, remotes/remote/carousel for remote/carousel, and so on.
You can, if you like, delete remote-tracking names using the git branch command: give it -d -r, i.e., the delete and remote options.
You can't—at least, not successfully—have your Git ask the Git at origin to delete remote/bridgent-carousel:
$ git push origin --delete remote/bridgent-carousel
error: unable to delete 'remote/bridgent-carousel': remote ref does not exist
error: failed to push some refs to 'git@github.com:Nostrad/<project_name>.git'
because the Git over at origin doesn't have this name. It's the Git over at bridgent that has—or at least had at one time—the name carousel. You can ask them to delete it, if you have permission. Or, you can delete the remote in your Git repository. The remote name, bridgent-carousel, stores the URL and enables your Git to have remote-tracking names of the form bridgent/*, or more fully, refs/remotes/bridgent/*.
2If you do, you can write refs/heads/origin/master and refs/remotes/origin/master, or just heads/origin/master and remotes/origin/master, to keep them straight. Do this just long enough to rename or delete the local branch named origin/master.
