Introduction — Git

Git Introduction

Git is the version control system used by virtually every software team on Earth. It tracks every change to your project, lets you rewind to any point in history, and makes it possible for thousands of people to work on the same codebase without stepping on each other. Linux, Windows, and the site you're reading right now are all developed with Git.

This tutorial series takes you from zero — never used version control — to confident daily Git use: committing, branching, merging, collaborating on GitHub, fixing mistakes, and even understanding what Git does under the hood.

What is version control?

A version control system (VCS) records changes to files over time so you can recall any earlier version. If you've ever created files like these, you've felt the need for one:

report-final.docx
report-final-v2.docx
report-final-v2-REALLY-FINAL.docx
report-final-v2-REALLY-FINAL-fixed.docx

Version control replaces that chaos with a clean, queryable history. With Git you can:

See every change ever made — what changed, who changed it, when, and why
Undo anything — restore a file, a folder, or the whole project to any past state
Work on ideas in parallel — try an experiment on a branch without touching the working version
Collaborate without overwriting each other — Git merges everyone’s work and flags genuine conflicts
Back up your entire history — every teammate’s machine holds a full copy

Not just for code

Git tracks any text-based files: documentation, configuration, websites, books, academic papers. If it lives in files and changes over time, Git can version it.

Why Git won

Git wasn't the first VCS — it followed tools like CVS, Subversion (SVN), and Perforce. Linus Torvalds created Git in 2005 to manage Linux kernel development, and within a decade it had displaced nearly everything else. Three properties explain why:

Distributed — older systems kept history on one central server; every operation needed a network round-trip, and the server was a single point of failure. In Git, git clone gives you the complete history. You can commit, branch, diff, and browse history offline; every clone is a full backup.
Fast — nearly everything happens locally, and Git's storage model (content-addressed snapshots) makes operations like switching branches and viewing history near-instant even in huge repositories.
Cheap branching — in SVN, branches were heavyweight copies people avoided. In Git, a branch is a 41-byte file — creating one is instant. That single fact changed how software is built: feature branches, pull requests, and open-source forking all flow from cheap branches.

	Centralized VCS (SVN)	Distributed VCS (Git)
History lives	On one central server	In every clone, fully
Work offline	Barely (no commits, no history)	Everything except push/pull
Branching	Expensive, discouraged	Instant, the default workflow
Single point of failure	Yes — the server	No — any clone can restore the project
Speed	Network-bound	Local, extremely fast

Git vs GitHub

A distinction that trips up every beginner: Git and GitHub are not the same thing.

	Git	GitHub
What it is	A version control program on your computer	A website that hosts Git repositories
Made by	Linus Torvalds (2005), open source	GitHub Inc. (2008), owned by Microsoft
Works offline	Yes, fully	No — it is a cloud service
Alternatives	Mercurial, SVN (rare today)	GitLab, Bitbucket, Codeberg, Gitea
Adds	Commits, branches, merges, history	Pull requests, issues, code review, CI, social features

Git works perfectly without GitHub — you can use it alone on your laptop forever. GitHub (and its competitors GitLab and Bitbucket) adds a shared home for repositories plus collaboration features like pull requests and issues. This series covers Git first, then the GitHub workflow on top of it.

The core mental model: three areas

Almost everything in Git makes sense once you understand that your project lives in three areas:

Working directory — the actual files and folders you see and edit. Your normal workspace.
Staging area (index) — a draft of your next commit. You stage exactly the changes you want to record, and leave the rest for later.
Repository (the .git folder) — the permanent history. A commit takes a snapshot of whatever is staged and stores it forever, with a message, author, and timestamp.

Bash

#  Working directory  --->  Staging area  --->  Repository
#        (edit)          git add           git commit

edit app.js          # 1. change files in the working directory
git add app.js       # 2. stage the change ("include this in the next snapshot")
git commit -m "Fix login validation"   # 3. record the snapshot in history

The staging area is Git's superpower and its most misunderstood feature. It exists so a commit can be a deliberate, curated snapshot — you might edit five files but commit only the two related to the bug fix, keeping history clean and reviewable.

Think in snapshots, not diffs

Each Git commit stores a snapshot of your entire project at that moment (efficiently — unchanged files are shared between snapshots). History is a chain of snapshots, and a branch is just a movable label pointing at one of them.

A taste of the everyday commands

Here's the loop you'll run dozens of times a day once you're fluent — each command gets its own detailed page later in the series:

Bash

git init                     # turn a folder into a Git repository
git status                   # what changed? what is staged?
git add index.html           # stage a file
git commit -m "Add homepage" # record a snapshot
git log --oneline            # browse history
git branch feature/nav       # create a branch
git switch feature/nav       # work on it
git merge feature/nav        # bring the work back
git clone <url>              # copy a remote repository
git pull                     # fetch + integrate teammates' work
git push                     # publish your commits

And here's what a real history looks like:

Bash

git log --oneline --graph

*   9f3c2ab (HEAD -> main) Merge branch 'feature/nav'
|\
| * 4e81d07 Add responsive navigation menu
| * 71b2c9e Add navigation markup
|/
* d3a5f10 Add homepage
* a1c9e42 Initial commit

Installing Git

Git runs on every platform. Check whether you already have it:

Bash

git --version

git version 2.45.2

Windows — install Git for Windows, which includes Git Bash. Covered in Install on Windows.
macOS — xcode-select --install or brew install git. Covered in Install on Mac.
Linux — sudo apt install git (Debian/Ubuntu) or sudo dnf install git (Fedora). Covered in Install on Linux.

After installing, tell Git who you are (this identity is stamped on every commit you make):

Bash

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

What this series covers

The tutorial is arranged in layers, each building on the last:

Basics — installing Git, configuration, init, add, commit, status, log, diff, and the file lifecycle. Enough to version your own projects.
Undoing things — restore, reset, revert, amending commits, the reflog, and recovering "lost" work. Git makes it very hard to truly lose anything.
Branching and merging — creating branches, switching, merging, resolving conflicts, rebasing, stashing, and tags.
Remotes and collaboration — GitHub, cloning, push/pull, forks, pull requests, code review, and team workflows (GitHub Flow, trunk-based, Gitflow).
Advanced tools — interactive rebase, cherry-pick, bisect, hooks, submodules, worktrees, and large-file handling.
Internals — objects, refs, the index, and packfiles. Optional, but once you see how simple Git's data model is, every command stops being magic.

How to use this series

Git is learned through fingers, not eyes. Create a scratch folder, run every command as you read, and break things on purpose — an experimental repo is free, and so is deleting it and starting over.

Ready to start

Next up: what version control is in more depth, installing Git on your platform, and making your very first commit. By the end of the basics section, Git will be part of your daily muscle memory.