Deep Dive into Git Storage Mechanism: Comprehensive Technical Analysis from Initialization to Object Storage

Git Storage Foundation

When executing the git init command in a Ruby on Rails project or any other project, Git creates a hidden folder named .git in the current directory. This folder serves as the core storage repository for the Git version control system, containing the complete version history, configuration information, and all tracked file versions.

.git Directory Structure Analysis

The .git directory, as the root container of the Git repository, features a carefully designed internal structure to support efficient version control operations. Key components include:

Objects Database: Located in the .git/objects/ directory, this is the core area where Git stores all versioned data. Each file version, directory structure, and commit record is stored as independent objects here.

References System: The .git/refs/ directory stores branch, tag, and other reference information. These references point to specific commit objects and form the foundation of Git's branch management.

Index File: The .git/index file serves as the staging area, recording file states ready for commit. It plays a crucial bridging role in git add and git commit operations.

Content-Addressable Storage Mechanism

Git employs a content-addressable storage strategy, which is central to its efficient version control. Each piece of content stored in the objects database is uniquely identified and located through SHA-1 hash values.

The following Python code example demonstrates how Git calculates the object storage path for files:

import hashlib

def calculate_git_object_path(file_content):
    # Construct Git object header format
    header = f"blob {len(file_content)}\0"
    # Combine header and content
    full_data = header.encode() + file_content
    # Calculate SHA-1 hash
    sha_hash = hashlib.sha1(full_data).hexdigest()
    # Generate object storage path
    object_dir = sha_hash[:2]
    object_file = sha_hash[2:]
    return f".git/objects/{object_dir}/{object_file}"

# Example usage
with open("example.txt", "rb") as f:
    content = f.read()
    object_path = calculate_git_object_path(content)
    print(f"File will be stored at: {object_path}")

This storage mechanism offers significant advantages: files with identical content are stored only once, regardless of how many times they appear in the project. When multiple files share exactly the same content, they reference the same Git object, substantially saving storage space.

Object Compression and Encoding

Git objects undergo zlib compression before storage to optimize efficiency. Original file contents are packaged into specific formats before compression.

The following code demonstrates how to decompress and examine Git object contents:

import zlib

def decompress_git_object(file_path):
    with open(file_path, "rb") as f:
        compressed_data = f.read()
    # Decompress data
    decompressed_data = zlib.decompress(compressed_data)
    return decompressed_data

# Parse object type and content
def parse_git_object(data):
    # Find null character separator
    null_index = data.find(b'\0')
    if null_index == -1:
        return None, None
    
    header = data[:null_index].decode('utf-8')
    content = data[null_index + 1:]
    
    # Parse header information
    parts = header.split(' ')
    if len(parts) < 2:
        return None, None
    
    obj_type = parts[0]
    obj_size = int(parts[1])
    
    return obj_type, content

Commit Operation Workflow

When executing git commit -a -m 'Initial', Git performs the following key steps:

1. Object Creation: Create blob objects for each modified file, storing them in the .git/objects directory.

2. Tree Object Construction: Create tree objects to represent directory structures, recording file names, permissions, and corresponding blob object references.

3. Commit Object Generation: Create commit objects containing author information, commit messages, parent commit references (empty for initial commits), and tree object references.

4. Reference Updates: Update current branch references (e.g., .git/refs/heads/main) to point to the new commit object.

Environment Variables and Custom Configuration

Git provides flexible environment variable configuration options, allowing developers to customize repository locations:

The GIT_DIR environment variable can specify the Git repository path. When set, Git uses the specified directory as the .git directory instead of searching in the current directory.

Additionally, repository and working tree paths can be explicitly specified via command-line parameters:

git --git-dir=/path/to/repository --work-tree=/path/to/working/tree status

This flexibility enables Git to support complex development workflows, including separated working trees and repository configurations.

Storage Optimization and Packfiles

As projects evolve, the number of Git objects may grow rapidly. To optimize storage and performance, Git periodically performs garbage collection (git gc), packing multiple loose objects into packfiles.

Packfiles employ delta encoding technology, storing differences between file versions rather than complete contents, further compressing storage space. This optimization is transparent to users, with Git automatically unpacking objects when historical versions are needed.

Cross-Platform Compatibility

In Windows systems, the .git directory is hidden by default. It can be viewed using the dir /AH command. Starting from Git version 2.9, users can also configure whether to hide the .git directory.

Git's internal storage format remains consistent across platforms, ensuring repository integrity when migrating between different operating systems.

Technical Evolution and Future Directions

Git continuously evolves its internal architecture. Starting from Git 2.18, the concept of raw object store was introduced, laying the foundation for supporting multiple repository operations and more flexible object management. These architectural improvements enable Git to better handle large projects and complex development scenarios.

The new object parser architecture separates raw object access from advanced object relationship management, providing better framework support for future performance optimizations and feature extensions.