Introduction to Git
Understand what version control is, why Git matters, and the mental model behind every command
Git is the tool that lets you save snapshots of your project, experiment without fear, and collaborate with other developers without overwriting each other's work. Nearly every software team on earth uses it — learning Git is not optional.
Why Version Control?
Without version control, saving progress means copying folders: project-final, project-final-v2, project-really-final. This breaks down fast — you can't tell what changed, you can't safely undo, and two people can't work on the same code at once.
Version control solves this by recording every change as a snapshot you can return to, compare against, or branch away from.
| Problem | Folder copies | Git |
|---|---|---|
| "What changed since yesterday?" | Diff folders by hand | git diff |
| "Undo the last 3 changes" | Hope you kept a copy | git revert / git reset |
| "Two people, one file" | Manual merge, overwrites | Automatic merge |
| "Why was this line written?" | No idea | git blame |
Git is distributed: every clone is a full copy of the entire history, not just the latest version. You can commit, branch, and view history with no network connection — the server (like GitHub) is just one more copy.
Git's Mental Model: Three States
This is the single most important concept in Git. Every file lives in one of three areas:
Working Directory → Staging Area (Index) → Repository (.git)
(your edits) (git add) (git commit)
- Working directory — the actual files you edit. Changes here are "untracked" or "modified".
- Staging area — a holding zone where you assemble exactly what your next commit will contain. You move changes here with
git add. - Repository — the permanent, immutable history.
git committakes what's staged and records it as a snapshot.
The staging area is what makes Git feel different from other tools. It lets you commit some of your changes and leave others for later — you craft each commit deliberately instead of dumping everything at once.
Your First Repository
Turn any folder into a Git repository with git init:
mkdir my-project
cd my-project
git init
# Initialized empty Git repository in my-project/.git/
Create a file, then check its status:
echo "# My Project" > README.md
git status
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
README.md
Git sees README.md but isn't tracking it yet. Stage it, then commit:
git add README.md
git commit -m "add project readme"
[main (root-commit) a1b2c3d] add project readme
1 file changed, 1 insertion(+)
create mode 100644 README.md
That a1b2c3d is the commit's SHA — a unique fingerprint of this exact snapshot.
Reading History
git log shows commits newest-first:
git log --oneline
# a1b2c3d add project readme
git status is the command you'll run most — it always tells you what state your working directory and staging area are in, and usually hints at the next command to run. When in doubt, run git status.
Before your first commit on a new machine, tell Git who you are — it stamps
every commit with this: git config --global user.name "Your Name" and git config --global user.email "you@example.com".