GitHub tells me the commit does not belong to any branch, while it's not


I’ve already asked another community of the same thing, but couldn’t get answered yet. Please help.

What I did

Yesterday, I rebased multiple commits on main branch of my repository through git rebase -i .

It was for the modification in commit messages, and I used the option --committer-date-is-author-date to remain previous commit history timestamps.

The problem

But after that, some commits from main history went wrong. I checked some main commits via GitHub’s commit history and found this:

GitHub commit history

This is the one specific example of the entire problem. GitHub told me the commit 91d64ce does not belong to any branch , but I wasn’t sure because I thought this means 91d64ce is a dangling commit, while actually it’s not .

When I take a look at main branch from Git GUI as below, It seems to be properly connected to parent and child, with main for the associated branch.

main branch visualization from Git GUI

Plus, git branch --contains returned main , which I expected.

The result was same though I double checked this through git clone -ing again to match repo status exactly.

$ git branch --contains 91d64ce450de36edb2feb86d9b45c2bf58203124
* main

$ git branch -r --contains 91d64ce450de36edb2feb86d9b45c2bf58203124
  origin/HEAD -> origin/main

The only problem is that wrong ‘does not belong to any branch’ notification on GitHub history of main .

My question is…

  • What happened?
  • Do commits like 91d64ce belong to main or not?
  • What solution should I apply to keep this repository clean?

Please consider that I’m not an expert to Git systems. Thanks in advance.

The problem is that without a link to the actual repository it’s hard to understand what request (i.e. link) produced the screenshot with the commit 91d64ce does not belong to any branch error.

My best guess here is that your were trying to access the old commit, i.e. via the its hash before the rebase operation. Beware that any history rewrite operation (commit amending, force pushes, rebasing, etc.) will change the hash of the commits involved. Every commit has a unique hash, and you can’t edit a commit without changing its hash.

So, if 91d64ce was the original hash of the commit that you edited, it’s correct that GitHub (and Git) report that commit as not being part of any branch, since it’s now deleted and replaced by a new commit — even if you only changed the commit message, the whole commit was replaced by a new one, which is an edited version of the original.

You should still be able to see the original 91d64ce commit in the RefLog (locally), which stores deleted elements for undo operations.

1 Like