This document provides a high-level introduction to Git's architecture and the major subsystems that comprise the Git version control system. It explains how commands are dispatched, how data is stored and accessed, and how the various layers interact. This overview is intended to provide context for the more detailed documentation that follows.
For detailed information on setup and versioning, see:
Git is a distributed version control system built on a layered architecture. The system consists of primary layers: the user interface layer that handles command dispatch, the command layer implementing porcelain operations, the core subsystems providing reusable functionality, and the storage layer managing persistent data.
Overall Git Architecture - Layer View
Architecture Layers
| Layer | Key Components | Responsibilities |
|---|---|---|
| User Interface | git.c | Command parsing, dispatching to built-in commands, alias resolution git.c529-700 |
| Command Layer | builtin/commit.c builtin/fetch.c sequencer.c | High-level porcelain commands users interact with directly |
| Core Subsystems | refs.c read-cache.c object-file.c diff.c revision.c | Reference management, index/staging area, object storage, diff generation, history traversal |
| Storage Layer | packfile.c odb.c shallow.c | Packfile compression, object database, shallow clone support |
| Platform Abstraction | git-compat-util.h wrapper.c | Cross-platform compatibility, safe system call wrappers |
| Build System | Makefile GIT-VERSION-GEN | Platform detection, compilation orchestration, version generation |
Sources: git.c1-900 Makefile1-100 read-cache.c1-200 git-compat-util.h1-100 GIT-VERSION-GEN1-107
When a user runs a Git command, it flows through a dispatch mechanism in git.c that handles options, aliases, and routing to the appropriate implementation.
Command Dispatch Table
The command dispatch table in git.c529-700 maps command names to implementation functions using struct cmd_struct git.c33-37
Key dispatch flags defined in git.c21-31:
RUN_SETUP - Requires a Git repository.RUN_SETUP_GENTLY - Try to find a repository but don't fail.USE_PAGER - Automatically paginate output.NEED_WORK_TREE - Requires a working tree (not bare repo).Sources: git.c21-37 git.c157-366 git.c466-527 git.c529-700
Git's data layer manages repository state through the object database, the index, and references.
The object database (ODB) manages persistent content storage. It handles both loose objects and packfiles read-cache.c21-22 The index, or "cache", acts as the staging area between the working tree and the ODB.
The index is loaded and managed primarily in read-cache.c It supports extensions like CACHE_EXT_TREE for directory invalidation and CACHE_EXT_SPARSE_DIRECTORIES for sparse index support read-cache.c68-75
References (branches, tags, HEAD) are managed through a pluggable backend system. The files backend stores refs in the filesystem, while the reftable backend provides a more efficient binary format.
Sources: read-cache.c1-200 read-cache.c68-75 read-cache.c133-154
Git maintains high portability through a compatibility layer.
The core of this layer is git-compat-util.h which includes platform-specific headers like compat/mingw.h git-compat-util.h161-168 and defines portability macros like ARRAY_SIZE git-compat-util.h88 Platform-specific logic, such as Windows error code translation, is handled in compat/mingw.c43-160
Sources: git-compat-util.h1-200 compat/mingw.c1-160
Git uses a complex build system primarily managed by a Makefile It supports auto-detection of platform capabilities via config.mak.uname and optional autoconf support via configure.ac Makefile14-19
Version strings are dynamically generated by the GIT-VERSION-GEN script. It attempts to use git describe to find the most recent tag and the number of commits since that tag GIT-VERSION-GEN40-58 If not in a git repository, it falls back to a default version string GIT-VERSION-GEN3
For details on building and versioning, see Getting Started and Build System.
Sources: Makefile1-50 GIT-VERSION-GEN1-107
