Inside Git: How It Works and the Role of the .git Folder

How Git internally works?

Git functions as a content-addressable file system and a directed acyclic graph (DAG) of project snapshots. It operates using fundamental known as Git objects, which are all stored in hidden .git directory in your project.

1. Content-Addressable Storage: Git’s fundamental principle it is that its store data as a key-value store. The key is a unique identifier generating a unique hash for every key-value store in git.

2. Immutability: Once an object stored, it is immutable. Changing a file content’s creates a new blob and a new hash.

3. Direct Acyclic Graph (DAG): Git models project history as a DAG, where commits are nodes, and each commit points to its parent commit(s), forming a chronological history.

Understanding the .git Folder

The .git folder is core of git repository, a hidden directory that contains all the metadata, object data (files, directories, commits) and configuration necessary for all Git to track and manage project history. It is essentially the entire database for project’s version control.

1. Version Control: The primary function of .git folder is to enable all Git functionalities, which are tracking changes, managing branches, and accessing commit history flow.

2. Data Integrity: Git uses content-addressable storage by SHA-1 or SHA-256 Algorithms to hash objects, ensuring data integrity to prevent conflicts.

3. Offline Work and Collaboration: It allows for a complete local copy of the repository history, enabling developers to work offline and synchronize changes later.

Git Objects: Blob, Tree, Commit

Git is built on a content-addressable storage system where all data is stored in four primary objects types: blob, tree, and commit (plus the less common tag object).

Each object is defined by a unique SHA-1 hash of its content.

Blob (Binary Large Object)

Purpose: A blob object stores the raw content of a file. It is the file data without any metadata like a filename, creation date or permissions.

Key Feature: Blobs are purely content-addressed. If the files in a repository (or even in different repositories) can have exact same content, they will reference the same immutable blob object, which save storage space through deduplication.

Tree

Purpose: A tree object acts like a directory entry in a filesystem. It solves the problem of storing the filename and directory structure.

Key Feature: A tree object contains a list of entries, each file with a mode (permissions), object type (blob or tree), SHA-1 hash and filename, and this allows trees to reference both files (blobs) and subdirectories (other trees), creating the full hierarchy.

Commit

Purpose: A commit object is a snapshot of your project at a specific point in time. It ties the project’s state to metadata.

Key Feature: A commit object includes:

1. A pointer to the root tree object for the snapshot.

2. Pointers to its parent commits(s), which links the history together to form a directed acyclic graph (DAG) .

3. Metadata such as the author, committer, date and commit message.

How Git Tracks Changes

Git tracks changes by using a content-addressable filesystem and a system of three main objects: blobs, trees and commits. Instead of storing file differences in every version. Git stores snapshot of project at each commit.

SHA-1 Hashes: Git uses the SHA-1 hash of an object's contents as its unique identifier (ID). This ensures data integrity and allows Git to quickly determine if content has changed by comparing hashes.

The Index (Staging Area): The index is a crucial intermediate layer between your working directory and your repository. It acts as a staging area where you prepare the next snapshot (commit). Git uses file metadata (like size and modification time) cached in the index to quickly check if a file in the working directory has changed, avoiding the need to re-calculate the SHA-1 hash of every file every time you run git status.