git 提交和 git 提交 object 之间的区别以及它们的存储方式

Question

The amazing git pro book, mentions the following:

commit object that contains a pointer to the snapshot of the content you staged. This object also contains the author's name and email address, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents)...

and further,

Your Git repository now contains five objects: three blobs (each representing the contents of one of the three files), one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata .

The first bold texts almost differentiate between commit and commit object without much clarifying it. The second bold texts tell us that a commit is stored , but does that mean a commit object is only temporarily created? Git gurus, please clarify this to me.

Answer 1

There's four kinds of objects in the repo's object db: blobs, trees, commits and (the annotated) tags. "A commit" is a commit object, stored in a repo's object db. That's it. You can actually build the zlib test/demo sources and zpipe -d a commit object's file to see exactly the text git cat-file -p will show you. It really is that simple.

Seriously: fetch the zlib source and build zpipe. Then do commands in a toy repo you build with --template= to shut off all the samples, or get really bare-bones and do this:

mkdir -p mytest/.git/{objects,refs}
echo ref: refs/heads/main >mytest/.git/HEAD
cd mytest
git status

to see that puts you in a fully-operational git repo. This is not a trick. Now make a file and git add it and say find . Then make a commit and say find again. cat or zpipe -d the files that showed up in the repo.

Answer 2

See jthill's answer , but to some extent I'll note that this is "just" a terminology issue. I put "just" in quote because terminology and semantics are crucial to actual understanding , and the phrase mere semantics kind of puts me on edge: semantics aren't mere at all. They are essential, Without semantics. nothing we say has any meaning.

A useful distinction is to say that a Git commit—the noun—refers to:

• the commit object, plus
• its supporting tree object and any sub-trees and blob objects

and therefore it's the entire saved snapshot plus the metadata. ¹ Meanwhile, a commit object —where we use the word commit as an adjective modifying the noun object —is merely the commit object itself, consisting entirely of commit metadata, since the saved snapshot is found indirectly through the tree line.

As matt points out in a footnote , we also have the verb form, to commit , which means to make one of these commit objects that uses a tree object that uses subtrees and/or blobs.

In the end, then, the semantics are:

• to commit: commit as a verb, meaning to make a commit;
• a commit: commit as a noun, meaning the whole ball of wax; and
• a commit object: commit as an adjective, modifying object, meaning the internal Git object that stores only the metadata part of the whole-ball-of-wax.

Humans being human, and natural language being what it is, you'll see the terms being used inappropriately, with the expectation that the reading/listening human will receive instead what the writing/speaking human intended to say.

---

¹ Note that this means that I disagree with jthill's definition, which defines commit and commit object as the same thing. That's OK. Different people can have different definitions. The aim of the last claim before this footnote is that we should try to understand what someone else meant , even if that requires adapting to their terminology for a while.