GIT Internal (part 1)

If you're a developer, you've probably used Git, and not just that, you probably use it daily. But have you ever wondered how Git is structured? What happens when we commit code or how code merging is handled?

In today’s post, let’s "dissect" Git, a revolutionary software in the programming world. Make sure you’ve already mastered some basic commands like git commit, git branch, and git merge,...

Everything is a hash

Yes, you heard that right. The world inside Git is nothing but hashes, even your code is represented as a hash. Keep this idea in mind because it relates to the next part.

Git Objects: Blob, Tree, and Commit

First, let’s briefly go over Git. The most basic component in Git is an object. Objects can be blobs, trees, or commits. And of course, all of them are identified by a hash.

Blob

• Blob (binary large object) contains the content of your code.
• It’s different from a file, as a file includes metadata (like creation date or file name), while a blob contains only the file's raw byte content.
• A blob is identified by a SHA-1 hash generated from its content.

Tree

• The tree maps the directory structure of your code and is also identified by a SHA-1 hash.
• Its content points to the hashes of blobs or other trees. Think of blobs as leaf nodes, and trees as non-leaf nodes in a tree structure.

In the example above, the tree corresponds to a file system where the root directory contains one file /test.js and one subdirectory /docs. The /docs directory contains two files: /docs/pic.png and /docs/1.txt.

Commit

• Commits are something you're likely very familiar with. They’re the result of the git commit command you use daily.
• A commit is like a snapshot, recording the state of the entire directory at a given point in time.
• A commit contains a pointer to the hash of the root tree, the author (the person who made the commit), the message (the commit message), and the commit time. Uniquely, a commit can also point to one or more previous commits (in the case of merging), known as parent commits.
• It’s also identified by a SHA-1 hash.
• Each commit represents a full snapshot when you git commit, not just a list of changes since the previous commit.

Q&A Section

At this point, some might wonder: if each commit contains the full snapshot of the directory at that moment, doesn’t that mean we have to store a lot of data with every commit?

Let's jump into an example. In the directory tree above, suppose we change the content of the file 1.txt from "HELLO WORLD" to "HELLO WORLD!". You can see that the tree and blob have changed (in red).

At first glance, it looks like the new commit saves a lot of data, but if you look closely, you’ll notice that unchanged parts remain the same.

In conclusion, if an object hasn’t changed, Git doesn’t create a new copy of that object but keeps the original intact.

Recap

• Blob: Contains the file content.
• Tree: Maps the directory and points to blobs and other trees.
• Commit: A snapshot of the working tree.
• For example, if I have a file with the content "Hello world" and you have a similar file, the blob hash will be the same because it’s hashed from the file’s content.
• Similarly, if I have a folder containing a subfolder and other files, and you have an identical folder with the same structure and file names, the tree hash will be the same.
• However, if you commit and I commit, the commit hashes will likely be different because they hash from the content of the author, commit message, and commit time.

In the next part, I'll talk about branches in Git. Stay tuned!