Introduction to Git

What is Git

Git is a distributed version control system (DVCS) designed to track changes in source code During software development. Unlike centralized VCS (CVCS) such as Subversion or Perforce — where a Single server holds the authoritative repository — Git treats every clone as a fully-fledged Repository with complete history. There is no intrinsic distinction between a “server” and a “client”; the difference is purely social (who pushes where).

Git was created by Linus Torvalds in 2005 to manage the Linux kernel source tree after the Proprietary license for BitKeeper was revoked. The design constraints of the Linux kernel project (millions of lines of code, thousands of contributors, high concurrency of merges) fundamentally Shaped Git”s architecture.

Here (e.g., `git switch``git restore`Sparse checkout) are unavailable in older versions.

Design Philosophy

Git’s design is the product of several deliberate trade-offs, each motivated by the Linux kernel Workflow:

1. Distributed by Default

Every repository clone contains the complete object database — every commit, every tree, every Blob. This means:

Offline operation: git log``git diff``git blame``git show all work without network access. You can commit, branch, and merge entirely offline.
Speed: Local operations read from the filesystem, not the network. git log on a cold repository scans the local object store.
Resilience: No single point of failure. If the remote server burns down, any clone can recreate it entirely with git push --mirror.

The cost is disk space — a full clone of the Linux kernel is $\sim$ 5 GB. Mitigations exist (shallow clones, sparse checkout, partial clone), but the default is to replicate everything.

2. Snapshots, Not Diffs

Most VCS (CVS, Subversion, Perforce) store a series of deltas: file $v_2$ is expressed as “file $v_1$ with these lines changed.” Git instead stores full snapshots of the entire project tree at Each commit. If a file has not changed between two commits, Git does not store it again — it stores A pointer to the identical blob object.

This design choice has deep implications:

Content-addressable storage: Every object is identified by the SHA-1 hash (or SHA-256, as of Git 2.29) of its content. Two identical files at different paths or in different commits produce the same blob object. This deduplication is automatic and transparent.
Fast branching: Creating a branch is a $O(1)$ operation — it writes a 41-byte reference file. There is no copying of file data.
Merge correctness: Three-way merge compares full tree snapshots, not a chain of deltas, which makes it robust against complex history topologies.

The cost is that Git’s object store can appear larger than a delta-based store for repositories with Very large files that change frequently. This is why Git added the packfile format (see Internals: Packing and Garbage Collection) to Compress objects using delta compression between similar objects.

3. Strong Integrity Guarantees

Every Git object (blob, tree, commit, tag) is identified by a cryptographic hash of its content Plus header. This means:

Tamper detection: If a single byte in any object is modified, its hash changes, and all objects referencing it become invalid. git fsck can detect this.
Deterministic builds: Given the same source tree and the same commit hash, you are guaranteed the same content. This is foundational for reproducible builds and supply-chain security.
No ambiguity: A commit hash uniquely identifies a snapshot of the entire project. Two developers referring to a3f2b1c are guaranteed to be referring to the same state.

4. Nearly Every Operation is Local

With the exception of git fetch``git pull``git push``git cloneAnd git ls-remoteEvery Git operation works on local data. This was a hard requirement for the Linux kernel workflow, where Contributors on dial-up connections needed to work efficiently.

How Git Compares to Other VCS

Feature	Git	Mercurial (Hg)	Subversion (SVN)	Perforce (P4)
Architecture	Distributed	Distributed	Centralized	Centralized
Storage model	Content-addressable snapshots	Content-addressable snapshots	Delta-based	Delta-based (server-side)
Branching model	Pointer-based ( $O(1)$ )	Bookmark-based ( $O(1)$ )	Directory copy ( $O(n)$ )	Streams (server-side)
Offline commits	Full	Full	No	Limited (shelving)
Performance at scale	Excellent (Linux kernel, Chromium)	Good (Facebook used it)	Degrades with large trees	Excellent with Helix Core
Learning curve	Steep	Moderate	Shallow	Steep
Binary file handling	Poor (use Git LFS)	Poor (use Largefiles)	Good	Good

[Git LFS](https://git-lfs.github.com/) or [Git Annex](https://git-annex.branchable.com/). Vanilla Git is optimized for text files.

Installation and Initial Configuration

Installation

Platform	Method
Linux (Debian/Ubuntu)	`sudo apt install git`
Linux (Fedora)	`sudo dnf install git`
macOS	`brew install git` (preferred over Xcode’s bundled Git)
Windows	git-scm.com or `winget install Git.Git`

Essential Configuration

## Identity — required for commits
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

## Default branch name (Git 2.28+)
git config --global init.defaultBranch main

# Editor for commit messages and interactive rebase
git config --global core.editor "vim"

# Default pull strategy: rebase instead of merge (see [Remotes](./04-remotes-and-workflows/01-remote-operations.md))
git config --global pull.rebase true

# Credential helper — avoids typing passwords repeatedly
git config --global credential.helper cache --timeout=3600  # 1 hour cache

Configuration Hierarchy

Git reads configuration from three levels, with later sources overriding earlier ones:

flowchart LR
    A["/etc/gitconfig<br/>(System-wide)"] --> B["~/.gitconfig<br/>(User-wide)"]
    B --> C[".git/config<br/>(Repository-local)"]
    C --> D["Environment variables<br/>(GIT_CONFIG_COUNT)"]
    D --> E["Command-line flags<br/>(-c key=value)"]

    style A fill:#e1f5fe
    style B fill:#b3e5fc
    style C fill:#81d4fa
    style D fill:#4fc3f7
    style E fill:#29b6f6

Use git config --list --show-origin to see all effective values and their sources.

Core Concepts Overview

flowchart TB
    subgraph "Working Directory"
        WD["Files on disk<br/>(your actual project)"]
    end

    subgraph "Index (Staging Area)"
        IDX["Snapshot of next commit<br/>(.git/index)"]
    end

    subgraph "Repository (.git)"
        OBJ["Object Store<br/>(.git/objects/)"]
        REF["References<br/>(.git/refs/)"]
        HEAD["HEAD pointer"]
    end

    WD -- "git add" --> IDX
    IDX -- "git commit" --> OBJ
    OBJ -- "git checkout" --> WD
    REF -- "points to commit" --> OBJ
    HEAD -- "points to branch ref" --> REF

    style WD fill:#fff3e0
    style IDX fill:#e8f5e9
    style OBJ fill:#e3f2fd
    style REF fill:#fce4ec
    style HEAD fill:#f3e5f5

These three areas — working directory, index, and repository — form the foundation of Every Git operation. Understanding the transitions between them is essential. See The Three Trees for a deep dive.

Guide Structure

This guide is organized into the following sections:

Section	Content
Fundamentals	Three-tree architecture, Git objects, references
Branching and Merging	Branches, merge strategies, rebasing, conflict resolution
Remotes and Workflows	Remote operations, branching strategies, pull requests
Advanced Topics	Reflog, stash, bisect, submodules, worktrees
Internals	`.git` directory layout, pack files, hashing algorithm
Others	Self-hosting, commit history removal

Common Pitfalls

Confusing git reset and git revert. Reset moves the branch pointer; revert creates a new commit that undoes changes.
Forgetting to pull before pushing when working collaboratively, leading to merge conflicts.
Forgetting that $O(n \log n)$ average-case for quicksort becomes $O(n^2)$ worst-case on already sorted input.
Neglecting to normalise database designs, leading to data redundancy and update anomalies.
Mixing up Big O, Big $\Omega$ , and Big $\Theta$ notation. Big O is an upper bound, not necessarily tight.
Writing pseudocode that is too language-specific rather than using standard algorithmic constructs.

Summary

The key principles covered in this topic are linked in the sub-pages above. Focus on understanding the definitions, applying the formulas or frameworks, and evaluating strengths and limitations of each approach.

Worked Examples

Worked examples demonstrating the application of key concepts are covered in the detailed sub-pages linked above.

Intuition

Git is a time machine for your code. Every commit is a snapshot you can return to, branch from, or compare. Unlike a simple backup system, Git tracks the relationships between snapshots, letting you merge parallel lines of work. The working directory is your workshop, the staging area is your prep table, and the repository is the archive. Branching is cheap and instant, so you should branch often and merge frequently to avoid conflicts.

Cross-References

Mark this page as reviewed