Git Internals - in a nutshell

-


Git Internals - in a nutshell


People use a tool or technology on a daily basis, sometimes for years, without truly understanding it in-depth or knowing how it really works. In this blog post, we will take a closer look at the wonderful world of Git.

Let's start by establishing what git is
Well, if we ask Dr. Google we will probably get the following answer: "Git is a distributed version control and version management system". Now, let's break down what we just read and see if we can find a more reader-friendly explanation.

So, here is the deal. Git is the most widely used version control system in the world and quite surprisingly it is actually a well maintained and super popular open source.

Why do we need git?
Well, first of all, Git is able to track changes in files by using snapshots of the filesystem. Try to imagine that instead of source code you and your team are working on the same Google doc. What would happen? you would basically override each other's changes. Think about it, what is a source code really? it is just a bunch of files and folders that different people need to be able to work with at the same time.

How does it work?
Basically, a standard git workflow would be defining and initiating a local working directory as a repository. In that repository, you can keep track of files within your working directory. You are then able to stage your changes before making a final snapshot (Commit), and then commit these changes. Eventually, the files with the updated changes should be pushed into a remote repository which will allow easy collaboration.

Git internals
When we first initialize a local Git repository (To convert an existing project in your file system or to initiate an empty repository), you actually create a new .git subdirectory. This new folder will contain everything you need to be able to apply git workflows.

Let's dive in...
So what does this mysterious folder contain?
For demonstration purposes, I have created an empty repo on my machine and named it "mySuperCoolRepo".
Executing this command in Linux based OS will present all of the subdirectories in our empty repo:

ls -ld .?*


inside our .git folder we find more surprises:



Once we step inside this folder we see that it contains the necessary metadata, Objects, Refs, templates, and a HEAD file which point to the currently checked-out commit.



Next up...

  • I'm going to remove the template sample files just to make the demonstration more clear. 
  • I'm also going to watch the .git subdirectory so we can see what actually happens in git internals "live". 
  • I'm creating a file called "mytextfile.txt" and adding some text into it.




  • Now, let's stage our file.



Once I staged my file we can see in the above screenshot that an object was created.
Let's take a look at this object.
When I present it in my terminal you can notice that it is a compressed binary file, I will use a shell command to open the content of this file.
As you can see in the below screenshot, this is, in fact, my "mytextfile.txt" I have staged.



So what actually happened is that my file has been compressed and stored on disk using something called SHA1 (Secure hashing algorithm). It contains all the data the original file contained without even mentioning the original file name (Which is stored in the index).


The index is a file Git uses to keep track of it's three main areas mentioned. The working directory, the staging area, and the committed repository. Once there are changes added to the staging area Git will update the index file and create the blob object (Like we saw happening in the above example).

So, the next step would be committing our changes right? Let's do that...


So, what just happened here?
We see that there are actually 3 objects created on disk. What are these objects?
Let's open the last object...





So, we learn from this that Git creates a tree object that maps a file on disk. (You might have seen Git being illustrated as a tree-like structure).
The type of this object is a "Commit".
We can actually access that commit object (Which has a tree reference) and view its details



In conclusion
This is an overview of Git internals in a nutshell and a quick introduction of how it works "under the hood". I always say that a lifetime isn't enough to learn everything I would like to and Git is not an exception.




Want to learn more cool stuff?

Click this link for more details about our Advanced Test Automation & DevOps course.



Comments

Post a Comment

Popular posts from this blog

Sharing is caring - Intro to Jenkins shared libraries

-
Image
  Whether you're just dipping your toes into the world of automation infrastructure, or already crafting your first jobs to automate your test execution, Jenkins is your new best friend.  In this blog post, we will talk a bit more about the practice of infrastructure as code, its relevance to test automation, and how you can avoid code duplications, align with industry best practices, and enable velocity, maintainability, and collaboration. So, whether you're a seasoned pro or just starting out, let's dive into the world of Jenkins Shared Libraries and see how they can make your life easier. Jenkins Shared Libraries play a crucial role in the realm of Infrastructure as Code (IaC).  So, what are they exactly? Think of Jenkins Shared Libraries as your secret stash of code snippets, neatly organized and ready to be plugged into your pipelines whenever needed. Let's explore the aspect of reusability within Jenkins Shared Libraries: Reusability is the cornerstone of efficien
Read more

Intro to Terraform and how it is related to test automation infrastructure

-
Image
In this post, we will take a closer look at one of the most popular infrastructure-as-code software tools developed by HashiCorp, and if you follow my recent content, that name should start ringing a few bells. So, what is Terraform and why do we need it? Terraform allows you to define and describe your infrastructure in the form of code. To be more specific “HashiCorp declarative configuration language” (or HCL in short). With Terraform you can manage your resources and infrastructure modules like servers, VPCs, security groups, and much more, even if they are located on different providers such as AWS or Azure.  Generally speaking, cloud providers have their own infrastructure-as-code tools like CloudFormation or ARM. But, Terraform has very extensive support for different cloud providers and platforms allowing you to use a single tool for cross-cloud configurations. This makes it easier to manage your resources, easier to onboard and this is a scalable and in general, the “best prac
Read more

Chromedriver - Under The Hood

-
Image
Selenium Webdriver has been our companion in our test automation adventures for some time now. Over the years the Selenium open source project has obtained something I can fairly describe as global domination. With Selenium, we are able to interact with different browsers using the WebDrivers. But, how much do we really know about them and the way they work? In this article, we will take a closer look into "Chromedriver" and explore a little bit about how it works. So, what is the role of this Webdriver? Starting from the release of Selenium 2, we were introduced to the concept of Webdriver. The "Chromedriver" for example is a .exe file that is able to act as a server. His role is to allow us to "Interact" with the browsers. Eventually, the responsibility for developing and maintaining these drivers was transferred to the browser vendors. The idea is, that they know their browsers the best and the produces driver would be much more stable and
Read more