Git Fundamentals

Analogy categoryAnalogies

Introduction

Git is a distributed version control system that lets teams track changes to source code over time. Unlike centralized systems, every developer's local clone contains the full history of the project, which makes Git fast, resilient, and well suited to collaborative software engineering.

🏏

Cricket analogy: Every franchise in the IPL keeps its own complete scorebook of every match ever played, not just a shared central ledger, so even if headquarters loses records, each team still has the full history.

Explanation

Git organizes work using a three-tree model: the working directory (the files you edit on disk), the staging area or 'index' (a snapshot of changes you intend to include in the next commit), and the repository (the committed history stored in the .git directory). git add moves changes from the working directory into the staging area, and git commit takes what is staged and permanently records it as a new commit in the repository, along with a message describing the change. git status shows the current state of all three trees — which files are modified, staged, or untracked — and git log shows the commit history so you can see who changed what and when.

🏏

Cricket analogy: A batsman practices shots in the nets (working directory), the selectors shortlist certain net performances for the final XI (staging), and the official scorecard permanently records the chosen team's innings (repository), with the scoreboard showing all three states at once.

Example

bash

# Check current state of working directory and staging area
git status

# Stage a specific file, then all changes
git add src/app.py
git add .

# Commit staged changes with a message
git commit -m "Add input validation to signup form"

# View commit history
git log --oneline --graph

# Merge feature branch into main (creates a merge commit, preserves history)
git checkout main
git merge feature/signup-validation

# Rebase feature branch onto latest main (rewrites commits, linear history)
git checkout feature/signup-validation
git rebase main

Analysis

git merge and git rebase both integrate changes from one branch into another, but they behave very differently. git merge creates a new merge commit that ties together the histories of both branches, preserving exactly what happened and when, which is safe for shared branches but can leave a cluttered history. git rebase instead replays your branch's commits on top of the target branch's latest tip, producing a clean, linear history — but because it rewrites commit hashes, it should never be used on commits that others have already pulled, since it can cause confusing conflicts for collaborators.

🏏

Cricket analogy: A merge is like combining two separate warm-up net sessions into one official record showing both happened in parallel, while a rebase replays a substitute's practice reps as if they happened right after the main squad's latest session, giving a clean single timeline.

Key Takeaways

Git tracks changes across three trees: working directory, staging area, and repository.
git add stages changes; git commit permanently records staged changes with a message.
git status and git log are your primary tools for inspecting current state and history.
git merge preserves full history via a merge commit; git rebase rewrites history for a linear log.
Never rebase commits that have already been pushed and pulled by others.