git：看起来不像分支的分支

You're better to think branches as heads (or pointers). What git log shows you is a DAG of the commits and a list of heads pointing to particular commits. What you can see at the current moment is something like: the php7 head is pointing to this commit. You cannot know in the past how the php7 head was moving since git allows us to move heads in a free manner.

Regarding git branch --merged [<commit>], look into its document, the command simply shows all the heads that can be reached from the <commit>. In your case, the <commit> is HEAD which means master. So the result is obvious: dashboard, master, and php7 are reachable from HEAD. Notice that by default git branch does not show remote heads, add -a option for that.

Now I think your questions could be answered.

Commits I remember doing on the php7 branch are all on the same orange line as master. If I merged and then deleted the branch (logical), why is it still listed as a branch at all?

Because it is not sure that in the past php7 was merged into master. Even if it was, it could be always that at some point later the php7 head was moved, so we cannot see the vestige of the merge caused by php7.

Why is there an extra "origin" label on the last of the php7 branch? I would think recent pushes would cause remote to look just like local, with only one "origin" label on the latest commit. Surely remote doesn't consider php7 to be not-yet-merged - that would be horrible, as that code is critical.

That label simply means that currently there are 2 heads -- php7 and origin/php7 -- pointing to that commit.

dashboard is not known by remote at all (https://github.com/OsakaWebbie/kizunadb) - how could that be?

Because dashboard was created locally and has never been pushed to remote.

I would be happy to delete it (I don't keep old branches for nostalgia), but git branch -d texlabels says: error: branch 'texlabels' not found. The most branchy-looking thing in the log isn't a branch? My head hurts.

You know the existing of the texlabels head just because you see its name in the commit message. But actually that head was deleted in the past thus at the moment you cannot delete it again.

Update:

To answer some more concerns of @OsakaWebbie

The --merged option is named based on the fact that, in normal development (i.e., you don't abnormally move heads, with git reset for example), if a head child can reach to a head parent, it means that parent was merged into child at some point in the past. In other words, child does inherit parent.

----------------------- child
         /
        /
     parent

But I empathise with you about this, actually there are complaints about the naming of git commands and their options.

Back to the story of your php7 head, I think the situation should be clear now.

A merge does not necessarily cause two paths joining into one. Indeed, as you told, since you switched to php7 and appended 46 commits to it, you hadn't appended any commit to master, so the history before the merge looks like this:

----------------- master
                    \
                     ----------------- php7

Then you switched back to master and made the merge: git merge php7. Because php7 is a child of master, the result of the merge should be exactly php7. Thus, git will simply move master forward and point it to the commit being pointed by php7. This kind of merge is called fast-forward. Then you have:

-------------------
                    \
                     ----------------- php7, master

which essentially is:

-------------------------------------- php7, master

But fast-forward did not happen with the merge of texlabels head. You created the head, switched to it, coded something and appended some commits. Then you switched back to master, also coded something and appended some commits. So you have:

----------------- master
     \
      ----------- texlabels

As you see texlabels is not a child of master. Hence this cannot be a fast-forward, merging texlabels into master will cause:

----------------- (old master) -- master
     \                         /
      ----------- texlabels

That's why it is the only branchy-looking thing in the history.

Regarding your two last concerns:

Oh, I didn't realize that a basic push doesn't include branch information. Apparently Github knows about php7 because I no doubt did pushes while it was checked out. (Is that right?)

git push <remote> [<head>] only pushes the provided <head> (and its ancestor commits of course). If <head> is not provided, then the head that is being pointed by HEAD will be used -- it is php7 in your case. To push all the heads, use --all option.

But if you're saying that there is some uncertainty about their merge status, is it safe to delete them? (Deleting things sounds scary, but if it's merely a pointer...)

Yes, heads are merely pointers, but please be careful: after deleting a head, some commits may be abandoned -- i.e., they cannot be reached from any head -- and will be cleaned (deleted) by the GC of git. If you are sure about what you are deleting, go ahead.

---

Some more notes:

1. The push -f is not related here, it causes unexpected things in the remote (e.g., losing some commits), not in the local.
2. By default git log shows only the commits that can be reached from HEAD, use --all option to show all commits.

Update #2:

About the 4 extra commits

It's very likely that at the commit 51738d1 minor edits you issued a git filter-branch command to massively modify something about those 4 commits (modify author names -- I guess). Then you had 4 new commits created (from a669fa0 to 3b1c25a). The 4 old commits (from cfcaa51 to 51738d1) are still there because they are still reachable from the heads refs/original/.... These heads were created by the backing-up mechanism of git filter-branch.

您完全可以删除这4个额外的提交。它们与4个“主要”提交完全无关。