Git Snapshot | Steps | Workflow — 2

In previous article, I covered the fundamental commands and steps necessary to create Git snapshots, also known as “committing changes”. However, in this piece, I aim to delve deeper into the report generated by Git after a commit, Git objects, how Git works under the hood

---

lets recap

In the diagram below, we illustrate the workflow for committing a new file in Git:

After committing changes, Git provides us with a commit report. In this section, we’ll delve into the significance of the SHA-1 checksum, decipher the meaning of the last line in the report, and explore the inner workings of Git’s commit process.

$ git commit -m "this is init commit"

[master (root-commit) ed942fe] this is init commit
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 example.txt

First and foremost, it’s important to emphasize that Git captures snapshots of files, rather than recording the differences between versions. In other words, Git focuses on snapshots, not on differences (diffs) between versions. SNAPSHOT not DIFFS.

Today, we will learn new terminologies and some commands that are not necessary during software development, but they allow us to understand Git’s operations under the hood.

Git Objects

If you’ve worked with key-value databases like Redis before, the core concept of Git is easy to understand. Git functions as a key-value data storage system, allowing you to store various types of content and providing a unique hash string as a key in return. This hash string, typically of type SHA-1, enables you to retrieve the contents later.

lets start with create a fresh local repository, after ‘init’ commad git creates a directory in of ‘.git’.

$ git init example

Initialized empty Git repository in /home/mehdi/git/example/.git/

In simple terms, the database I mentioned earlier will be located in the ‘.git’ directory. If you head to the ‘.git/objects’ directory, you’ll see ‘info’ and ‘pack’ subdirectories. They are belongs to Git and this is the place that Git uses as their object database.
When you start a fresh repository there is nothing in ‘objects’ direcotry.
There is a ‘hash-object’ command which create a data object and we can manually store data in Git key-value database and in return gives us a 40 character hash string in SHA-1.

Before that, let’s check the ‘objects’ directory with the following command. As of now, it will return nothing.

$ find .git/objects -type f

Now, we’ll proceed to create our first data object manually using the ‘hash-object’ command. We’ll include additional flags like ‘-w’, which stands for write and indicates that we’re writing content into the database, and ‘-stdin’, which means we’ll read from stdin or the command-line.

$ echo 'Hello im mehdi' | git hash-object -w --stdin
4086ef4e53b8c4ab5a6aa37833db8c6c5032cf9d

lets check the ‘objects’ directory

$ find .git/objects -type f
.git/objects/40/86ef4e53b8c4ab5a6aa37833db8c6c5032cf9d

My ‘Hello, I’m Mehdi’ is stored in the Git database as an object. I can retrieve this data using the ‘cat-file’ command. The first two characters of the hash string represent the object directory, while the rest is a simple blob file, which I’ll discuss in the next part. Lets try to retrive our object in human readable output.

$ git cat-file -p 4086ef4e53b8c4ab5a6aa37833db8c6c5032cf9d
Hello im mehdi

Good, Lets keep it short.

In conclusion

we’ve explored the foundational concepts of Git, including its snapshot-based approach and key-value database structure. Understanding these core principles. We’ve also familiarized ourselves with new Git commands and terminologies, providing a solid foundation for further exploration and mastery of this powerful version control system. In next part we will read about “tree object” and blob files.