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
Tree
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
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
In the next part, I'll talk about branches in Git. Stay tuned!