Skip to main content

Command Palette

Search for a command to run...

How Git Works: The Importance of the .git Folder Explained

Updated
4 min read

How Git works internally..

There is a common misconception that you also might have that git keeps tracks of files or it keeps track of every line changes and i you are one of them it is actually very common I was also one of them but after going through a cohort class about git i might say i was enlightened . Git does not track files ,it tracks snapshot of your project files .Every time you commit it tracks the state of all files at that moment.

Understanding the .git Folder …

When you initialize a Git repository, a hidden folder named .git is created. This folder is the main of your repository. It contains all the necessary information to track changes, including your project's history, configuration settings, and pointers to the current state of your code.

  • objects/: This is Git's database. It stores all your file contents, directory structures, and commit history as unique objects. Here "object" includes:

    • blobs (files)

    • trees (directories)

    • commits (reference to a tree, parent commit, etc.)

  • refs/: This directory contains pointers (references) to the tips of your branches and tags.

  • HEAD: A special file that points to the current branch reference, telling Git "where you are" right now.

  • index: A binary file that serves as your staging area.

  • config: A file containing the repository-specific configuration options, such as the remote URL and user information

Git Objects: Blob, Tree, Commit /-

  • Blob (Binary Large Object): Stores the content of a file. It does not contain the filename or permissions.

  • Tree: Represents a directory. It contains a list of filenames and pointers to their corresponding blob or other tree objects.

  • Commit: A snapshot of your project at a specific point in time. It points to a root tree object and includes metadata like the author, date, and a link to its parent commit(s).

How Git track changes

When you're working with git, your files are saved in one of Git's 3 states:

  • The Modified State – This is when you add, remove, or change something in a file. Git has noticed the change but you have not formerly informed Git of the change yet.

  • The Staged State – This is when you inform Git of the change and tell Git to take note of that change. Commonly known as the "Staging Area", files in this stage are called the Staged Files. You can modify a file even after staging it, which lets you see the file both in a modified state and a staged state. The modifications made after the staging will not appear after a commit has been made.

  • The Committed State – This is when Git has saved your modified changes.

You can use the command git status to see which states your files are currently in.

When you commit some code, Git takes a snapshot of that particular version of your code which you can reference at a later stage.

So you could say Git is a database of references to your project. That database is built using three types of objects:

  • the commits which contain the metadata of every commit such as the message and author,

  • the tree of changes which contain references to filenames, file contents, and sometimes other trees,

  • and the blob which represents the actual data held within the files.

When working with Git, there are many moving parts and sometimes we're working with several different files.

In order for Git to keep track of all these files, it creates something called the Secure Hash Algorithm (SHA), which is a series of cryptographic hash functions, and assigns it to each commit. This makes it easier to identify duplicates and give them the same identifier as the original file, therefore saving storage.

Using the SHA, we can reference anything in Git like looking at a commit and reverting back to it, or just tagging it.

More from this blog