Git Fundamentals Theory

1. Version Control Systems Architecture

Version Control Systems (VCS) are critical infrastructure in professional software engineering, responsible for tracking modifications to source code assets, facilitating concurrent development, and establishing auditing logs.

Version Control Paradigms

graph TD
    A["VCS Paradigms"] --> B["Local VCS<br>Simple file copy database"]
    A --> C["Centralized VCS (CVCS)<br>Single repository server (SVN, Perforce)"]
    A --> D["Distributed VCS (DVCS)<br>Decentralized peer repositories (Git, Mercurial)"]

1. Local Version Control Systems: Historical mechanisms involving local databases that recorded file changes. They are highly vulnerable to localized data loss and lack concurrent multi-developer support.
2. Centralized Version Control Systems (CVCS): Systems utilizing a single centralized server repository. Clients checkout files from a central node. This introduces a single point of failure (SPOF) and degrades performance, as metadata queries require network operations.
3. Distributed Version Control Systems (DVCS): Modern architecture where clients fully mirror the repository, including the entire historical timeline and database. Git belongs to this category. If any node fails, any client repository can reconstruct the database.

2. Git Internals: DAG and Object Model

Git differs fundamentally from traditional version control systems (like SVN) by tracking changes as snapshots rather than diff-based delta lists. It models repository history as a Directed Acyclic Graph (DAG) of commit nodes.

graph LR
    C1["Commit 1: Root<br>Hash: 9e32a10"] --> C2["Commit 2: Parent<br>Hash: 4f88b2c"]
    C2 --> C3["Commit 3: Child<br>Hash: 7a89f92"]

Content-Addressable Storage & SHA-1

Git stores all source code assets inside a content-addressable key-value store database located in the hidden .git directory. The key is a 40-character hexadecimal SHA-1 checksum hash, computed directly from the byte-payload of the content and its header details.

The Four Core Git Object Types

The Git object database contains four distinct primitive models:

1. Blob: Binary Large Object. Stores raw file content byte-streams. Blobs do not contain file metadata, directory path hierarchies, or filenames.
2. Tree: Represents a directory layer. A tree object lists file names, paths, permissions, and links them to their corresponding blob hashes or sub-tree objects.
3. Commit: Holds metadata (author name, email, timestamp, message) and a pointer to the root tree object hash representing the project snapshot, along with one or more parent commit hashes.
4. Tag: An annotated reference pointer that assigns a persistent name (such as a version release identifier) to a specific commit.

• Self-Check: I can explain the architectural difference between delta-based version control and Git snapshot-based version control. (Click to check)
• Self-Check: I understand the role of SHA-1 content hashes in ensuring repository data integrity. (Click to check)

3. The Three Staging States

Git divides the local workspace environment into three distinct logical boundaries:

graph LR
    WD["1. Working Directory<br>Local file alterations"] -->|"git add"| SA["2. Staging Area (Index)<br>Preparation manifest"]
    SA -->|"git commit"| RP["3. Repository (.git)<br>Persistent snapshot"]
    RP -->|"git checkout / reset"| WD

1. Working Directory

The local sandbox where files are added, deleted, and modified. Git monitors this state but does not commit these changes until they are explicitly staged.

2. Staging Area (Index)

A simple binary file (located at .git/index) that serves as a preparation manifest. It lists all modified files and specific diff hunks prepared to be integrated into the next commit snapshot. This separation allows developers to craft precise, cohesive commits.

3. Git Repository

The persistent database where Git stores all historical snapshots as commit objects. Once changes are committed here, they are stored securely and can be retrieved or reverted.

• Self-Check: I can explain the function of the .git/index file as a staging area staging manifest. (Click to check)

4. Core CLI Operations & Workflow

Initializing and Cloning Repositories

To convert a plain local workspace directory into a managed Git repository:

git init

This initializes a blank repository by creating the hidden .git/ folder containing directories for hooks, objects, refs, and the local configuration file.

To copy an existing remote repository locally:

git clone https://github.com/username/project-repo.git

Repository Status & Tracking Inspection

To inspect file tracking categories:

git status

This command displays:

• Untracked files: Files created locally that have never been staged.
• Unstaged changes: Modified tracked files that are not yet recorded in the index.
• Staged changes: Files added to the staging area, ready to be committed.

Staging Changes

To add specific file changes to the staging area:

git add source_code.py

To stage all modifications in the current directory:

git add .

Staging Control (Interactive Hunk Selection)

To selectively stage specific parts of a modified file:

git add -p source_code.py

This launches an interactive utility allowing you to split, accept, or reject specific changes (hunks) within a single file.

Recording Snapshots

To commit staged changes to the repository:

git commit -m "feat: implement customer transactional balance validation"

To modify the message or contents of the most recent commit:

git commit --amend -m "feat: adjust balance validation limits"

[!WARNING] Only use --amend on local, unpushed commits. Rewriting already pushed commits can disrupt collaboration.

History Log & Comparisons

To view a linear timeline of commits:

git log --oneline

To view history with branch topologies:

git log --graph --oneline --all

To compare the working directory with the staging area:

git diff

To inspect staged changes prepared for commit:

git diff --staged

• Self-Check: I can selectively stage file changes using interactive hunk staging operations. (Click to check)
• Self-Check: I can use git log --graph to inspect branched commit topologies. (Click to check)

5. Reverting Modifications & Reset Mechanics

Git provides robust mechanisms to undo changes, ranging from safe local discards to rewriting commit histories.

Discarding Unstaged Local Modifications

To revert local changes in a file before staging:

git checkout -- source_code.py
## Or using the newer, explicit command:
git restore source_code.py

Unstaging Files (Staging-to-Working-Directory)

To remove a file from the staging index without losing your modifications:

git reset HEAD source_code.py
## Or:
git restore --staged source_code.py

Reverting Committed History

To undo an already pushed commit safely by creating a new commit that applies the inverse changes:

git revert <commit-hash>

Reset Mechanics: Soft, Mixed, and Hard

To reset the current branch pointer to a specific historical commit:

git reset --soft <commit-hash>

• Behavior: Moves the HEAD branch pointer to the target commit. The staging index and working directory remain unmodified. Your changes are preserved in the staging area.

git reset --mixed <commit-hash>

• Behavior: (Default mode) Moves the HEAD branch pointer and resets the staging area index. Your working directory is preserved, meaning all changes are kept as modified but unstaged.

git reset --hard <commit-hash>

• Behavior: Moves HEAD branch pointer, resets staging index, and discards all changes in the working directory.

[!CAUTION] A --hard reset completely discards all uncommitted work. Ensure your files are staged or committed elsewhere before executing this command.

• Self-Check: I can contrast the architectural behaviors of --soft, --mixed, and --hard resets. (Click to check)
• Self-Check: I understand when to use git revert instead of resetting branch history. (Click to check)

6. Branching, Merging, and Conflict Resolution

Branching Mechanics

In Git, a branch is simply a lightweight, mutable pointer to a specific commit. HEAD is a special pointer that references the current branch.

## Create a new branch
git branch feature/validation

## Switch to the branch
git checkout feature/validation
## Or using switch:
git switch feature/validation

## Create and switch in a single command
git checkout -b feature/validation
## Or switch equivalent:
git switch -c feature/validation

Merging and Merge Types

To merge a branch into your current branch:

git checkout main
git merge feature/validation

graph TD
    A["Merge Type"] --> B["Fast-Forward Merge<br>Pointer simply advances forward"]
    A --> C["Three-Way Merge (3-Way)<br>Creates a new merge commit"]

1. Fast-Forward Merge: Occurs if no new commits have been made on the target branch (e.g. main) since you created the feature branch. Git simply moves the pointer forward. No merge commit is created.
2. Three-Way Merge: Occurs if the target branch has diverged with new commits. Git uses a common ancestor, compares the tips of both branches, and creates a new commit containing the integrated changes.

Anatomy of a Merge Conflict

A conflict arises when developers modify the same lines in the same file differently across branches. Git will halt the merge process and mark the conflicted sections:

<<<<<<< HEAD
## Changes on the current branch (e.g., main)
return base_value * 1.15
=======
## Changes from the merging branch (e.g., feature)
return base_value * 1.18
>>>>>>> feature/validation

Resolving Conflicts Step-by-Step

1. Run git status to locate conflicted files.
2. Open conflicted files and manually remove the conflict markers (<<<<<<<, =======, >>>>>>>).
3. Refactor the code to integrate the correct changes.
4. Stage the resolved files: git add <file>.
5. Complete the merge transaction: git commit.

• Self-Check: I can resolve merge conflicts manually and compile the commit transaction successfully. (Click to check)
• Self-Check: I understand why fast-forward merges do not generate merge commits. (Click to check)

7. Remote Synchronization & Collaboration

Adding Remote Configurations

To link a local repository with a remote hosting server:

git remote add origin https://github.com/username/project.git

To view configured remote servers:

git remote -v

Fetch vs. Pull Operations

## Fetch changes
git fetch origin

• Fetch: Downloads new refs, commits, and tags from the remote repository but does not merge them into your local working directory. It updates remote-tracking branches (e.g. origin/main).

## Pull changes
git pull origin main

• Pull: Downloads changes and merges them into the current local branch. Equivalent to running git fetch followed by git merge.

Stashing Modifications

To temporarily save your uncommitted changes without making a commit:

git stash save "Work in progress on user checkout"

To list saved stashes:

git stash list

To restore and remove the most recent stash:

git stash pop

Tagging Releases

To tag a specific stable commit with a release version:

git tag -a v1.0.0 -m "Release version 1.0.0"
## Push tags to remote server
git push origin --tags

• Self-Check: I can explain the operational differences between fetching and pulling from a remote tracking branch. (Click to check)
• Self-Check: I can use the stash index to context-switch between feature tasks. (Click to check)