I would like to understand better the git commits associated with tags.

For context reasons, there is a public repository called deg/re-frame-firebase (

However, the tag is not shown on the git log of master branch:

Hence, since it is not on master branch, I assume it is on a different branch, coming from a Pull Request. But there is no Pull Request

CodePudding user response：

Your first step in the Zen of Git here is to realize that branches and tags do not matter. The only things that really matter are the commits.

After clicking on the commit associated to the tag (which is bd60d55)

More precisely, it is commit bd60d55815b6168210049510bb5d033301de3cb8.

That is the name of the commit. Forget about branch names and tag names, at least for now: bd60d55815b6168210049510bb5d033301de3cb8 is the commit.

If you have a Git repository and your Git repository has bd60d55815b6168210049510bb5d033301de3cb8 in it, it has that commit in it. Any Git repository, anywhere on earth, that has commit bd60d55815b6168210049510bb5d033301de3cb8 in it, has that commit. Any Git repository that does not have bd60d55815b6168210049510bb5d033301de3cb8 does not have that commit.

If at this point you can remember bd60d55815b6168210049510bb5d033301de3cb8 now and forever, that's all you need. But if you're like me, you probably don't remember bd60d55815b6168210049510bb5d033301de3cb8 even after you paste it seven times. That's when a name, like v0.10.0, is useful: if you can remember that, Git will—under the right conditions, which are easy to achieve—use that to find the big ugly hash ID that I've already forgotten. And that will find the commit, and now you're done. It's the commit that matters, and Git needs the hash ID, and you can remember the tag name instead of the hash ID.

The weird thing, though, is that I cannot find [the file named src/com/degel/re_frame_firebase/storage.cljs.

Files, in Git, are stored in commits. If you can find the commit, that's where you'll find the file. Technically, the commit itself contains just some metadata that allow Git to find the tree objects that allow Git to translate the file name to a blob hash ID that finds the blob object that holds the file's content—but you don't need to know all that. What you do need to know is that it's the commit hash ID, plus the path name, that get you this.

The second thing is that I can access version v.0.10.0 via git checkout ...

You can get to the commit with git checkout or git switch --detach, both of which will fill in your working tree from the full contents of that particular commit.

Each commit, in Git, holds a full snapshot of every file, frozen in time, as of the form it had at the time whoever made the commit, made that commit.

(Internally, these are stored as blob objects found via tree objects found via the commit metadata found via the commit. These objects themselves are stored compressed and de-duplicated, so every commit that shares some particular version of some particular data literally shares that file-version with every other commit that has the same data. Furthermore, objects are often delta-compressed against other objects—but this happens invisibly, below the level at which commits, trees, and objects exist. So again you don't really need to know all of this: you can just be assured that Git usually does a fairly good job of storing every version of every file ever committed without wasting much disk space.)

Each commit lists, in its metadata, the hash ID(s) of some previous ("parent") commit(s). In this particular case, commit bd60d55815b6168210049510bb5d033301de3cb8 has one parent, which is commit 432dac15092af1b8681a5cc4e69cb93433f3a5fc. All of the files inside each of these two commits match except for the file named src/com/degel/re_frame_firebase/storage.cljs, which has the one typo fixed in the newer commit. A lot of Git viewers—including git log and GitHub's web browser view—"like to" show you the differences between the non-matching files, since that's usually what humans like to see.

Since [this particular commit] is not on master branch, I assume it is on a different branch ...

It could be on one or more branches. It could be on no branch. As long as you memorize its hash ID, you can find it that way, and if you don't know its hash ID, you can use some other name to find it.

Once you grok the above, it's time for a few last questions

Philosophical question: if you can't find it, does it exist? ("It" here is probably a commit, but this applies to everything where the pronoun fits.)

Practical question: If it had existed at one point, but you couldn't find it then and can't find it now, and Git may or may not have deleted it, does it exist?

The point of branch names is that they help you—and Git—find the latest commit "on" some branch. Any commit can be "on" any number of branches, from "none" to infinity (if you can create an infinite number of branches anyway), but the very definition of a branch name is that whatever commit hash ID it holds, that commit is the latest commit on the branch. So whatever hash ID is in some branch name, that's the last commit. From here, Git uses the stored parent hash ID(s) to work backwards in time.

The point of tag names is that they help you and Git find one specific commit. This is the same as a branch name! However, there's no corresponding "by definition" part here: a tag attached to a commit hash ID doesn't imply anything special about the commit, other than "some human thought it was worth giving a human-readable name". Since these names are assigned by humans, for human purposes, there's not too much more to say here, except that Git makes a somewhat feeble attempt to keep humans from re-assigning the same tag name to a different commit later. That attempt is easy to override, but if you do it, remember that not everyone will pick up the update. By contrast, people who pick up branch names are expected to assume that the branch name will "move" over time, since the commit that is "the latest" changes over time.

You now understand Git branching!