Git and Version Control Foundations

Why version control?

Version control tracks every change to a codebase over time, so teams can collaborate without overwriting each other's work, recover any previous state, and understand exactly how a project evolved.

Git is a free, open-source, distributed version control system (DVCS) created by Linus Torvalds in 2005 to manage the Linux kernel's source code.
GitHub hosts Git repositories in the cloud and layers on collaboration features — pull requests, issues, and code review.
Being distributed means every developer has a full copy of the repository's history, not just a pointer to a central server.

Key idea: Git tracks snapshots of your whole project, not just line-by-line diffs — which is what makes branching and merging fast.

Core building blocks

Concept	What it is
Repository	The project's files plus its full Git history
Working directory	The files you're actively editing
Staging area	Changes queued up for the next commit
Commit	A saved snapshot of the project at a point in time
Branch	An independent line of development
Merge	Combines the changes from one branch into another

A commit is identified by a unique hash and records what changed, when, and why (via its message).
Branches let you experiment or build a feature without touching the stable main branch.
Merging replays or combines commits from one branch onto another once the work is ready.

The everyday workflow

Most day-to-day Git work comes down to five commands, run in this order:

git status                    # see what's changed
git add <file>                # stage a specific file (or `git add .` for everything)
git commit -m "message"       # snapshot the staged changes
git push origin <branch>      # publish local commits to a remote
git pull origin main           # fetch and merge remote changes into your branch

git log walks back through commit history; git diff shows exactly what changed and where.
git clone <url> creates a full local copy of a remote repository, history included.
Always pull before you push — it keeps your local branch in sync with your teammates' work.

Branching, pull requests, and undoing mistakes

Non-linear development means a feature can be built in isolation, reviewed, and merged only once it's ready:

git switch -c feature/login    # create and move to a new branch
# ...make changes, commit them...
git push origin feature/login  # push the branch, then open a pull request on GitHub

A pull request asks a teammate to review the branch's changes before they're merged into main — the point where most code review happens.

git switch <branch> — move between existing branches
git restore <file> — discard uncommitted changes to a file
git revert <commit> — safely undo a commit by creating a new, opposite commit (keeps history intact)
git rerere — remembers how you resolved a merge conflict before, and reapplies that resolution automatically the next time it sees the same conflict

Naming releases: semantic versioning

Version numbers communicate what changed and whether it's safe to upgrade. The most common convention is semantic versioning — MAJOR.MINOR.PATCH:

Major (1.0.0 → 2.0.0) — breaking changes; existing code may need updates
Minor (1.0.0 → 1.1.0) — new, backward-compatible functionality
Patch (1.0.0 → 1.0.1) — backward-compatible bug fixes only

Tip: reading a dependency's version bump before upgrading tells you how much testing you should budget for the change.