Core Concepts of Git: Theory, Architecture, and Workflow

Git is a distributed version‑control system (DVCS) that stores complete snapshots of files rather than incremental patches. Version‑control systems can be classified into local, centralized, and distributed types, each with different storage and collaboration characteristics.

In a distributed system such as Git, every clone contains a full repository—including the complete history, commits, and references—so the loss of a single server does not jeopardize the project.

Git’s internal data model consists of three primary object types:

Blob : stores the raw content of a file.

Tree : represents a directory, containing references to blobs and other trees along with mode, type, and filename metadata.

Commit : points to a top‑level tree, records author/committer information, timestamps, parent commit IDs, and a commit message.

Each object is addressed by a 40‑character SHA‑1 checksum, which serves as a content‑based pointer ensuring data integrity. Identical file contents share the same blob and checksum, so unchanged files across commits only add a reference, not a new object.

Git maintains three work areas: the working directory, the staging (index) area, and the local repository. Changes flow from the working directory to the index via git add, and from the index to the repository via git commit.

File states are modified , staged , or committed . The typical workflow is:

Modify, add, or delete files in the working directory.

Run git add to stage the new snapshots.

Run git commit to create a commit object that permanently records the staged state.

References (or refs) provide human‑readable names for SHA‑1 IDs. The most common ref is master (or main), which points to the tip of the default branch. The HEAD file stores the current branch reference, and tags are immutable refs that point to specific commits.

$ git log Shows the commit history with SHA‑1 IDs, authors, dates, and messages.

Branches in Git are lightweight pointers to commits. Creating a branch merely writes a new ref file containing the target commit’s SHA‑1. Switching branches updates HEAD and checks out the corresponding snapshot.

Merging combines histories. A fast‑forward merge simply moves the branch pointer when the histories are linear. A true three‑way merge creates a new commit with two parents when divergent histories must be reconciled.

Rebasing rewrites history by replaying a series of commits onto a new base, producing a linear, cleaner log. After rebasing, a fast‑forward merge can be performed.

In summary, Git’s design relies on content‑addressable storage, immutable objects, and simple reference files to provide powerful, efficient distributed version control.