Files are untracked. Git doesn’t know what to do with them. To commit a file you need to put it in a staging area (whatever it is in staging area it will go in the next commit).
git add/git commit
A commit is compressed like a blob. If we git cat-file the commit we will see that a commit is a simple, short piece of text. Git generates the commit and stores it like a blob. The commit contains all the metadata about the commit (the name of the author, the committer, the date of the commit, the message).
Mariuss-MacBook-Air:cookbook mariusistudor$ git cat-file -p 5a464f88150a3d1c406da815c60e712099e7b4b6
tree be4d5bfce489a2591e7fed5c672f9e52cd695a43
author Marius Istudor <[email protected]> 1584872355 +0200
committer Marius Istudor <[email protected]> 1584872355 +0200
First commit
Plus, it contains the SHA1 of a tree (the way a blob is a file stored in Git, a tree is a directory stored in Git). The commit is pointing to the root directory of the project.
The blob is not a file, it is the content of a file. The file name and the permissions are not store in the blob, they are stored in the tree that points to the blob. If you have the same data, you will get the same hashes. For commit, it will be different, because it will have different content (author, date, etc).
Git tags
A tag is a label for the current state of the project. There are two types of tags in git: regular and annotated.
Annotated tags are created using the git tag command and contain metadata such as name of the tag, message, time and date and an object that the tag is pointing to. A tag can be simply considered as a simple label attached to an git object.
So, the Git object models contains:
blobs (arbitrary content)
trees (directories)
commits
annotated tags
Git can be considered like a high-level file system based on the native file system. Because it uses versioning (by commits) it is also considered a content tracker.
