Git

A version control system that tracks every change to your files over time, so you can go back to any previous version, work on multiple ideas in parallel, and collaborate without overwriting each other’s work.

What is it?

You have almost certainly done something like this: saved a file as report.docx, then saved a copy as report-v2.docx, then report-FINAL.docx, then report-FINAL-FINAL.docx. Eventually you have a folder full of versions and no idea which one is actually the latest or what changed between them.¹

Git solves this. Instead of making copies, Git tracks every change to every file in your project over time. Each change is recorded as a commit — a snapshot of the entire project at a specific moment, with a message explaining what changed and why. You maintain one copy of each file, but you can recall any previous version at any time.²

Git was created in 2005 by Linus Torvalds — the same person who created Linux. The Linux kernel had thousands of contributors editing the same codebase simultaneously, and the existing tools could not keep up. Torvalds built Git to be fast, distributed (every developer has a full copy of the history), and reliable under extreme collaboration pressure.³

Today, Git is the most widely used version control system in the world. It is the foundation of platforms like GitHub, GitLab, and Bitbucket. It underpins virtually every professional software project. And it matters more than ever for people building with AI tools, because when an AI generates code you do not fully understand, Git is your safety net — the ability to undo, compare, and roll back.⁴

In plain terms

Git is an unlimited undo button for your entire project. Every time you save a checkpoint (commit), Git remembers the exact state of everything. You can jump back to any checkpoint, compare any two checkpoints, or branch off to try something experimental without affecting the main version. If the experiment fails, you delete the branch. If it succeeds, you merge it in.

At a glance

The basic Git workflow (click to expand)
graph LR
    WD[Working Directory] -->|git add| SA[Staging Area]
    SA -->|git commit| LR[Local Repository]
    LR -->|git push| RR[Remote Repository]
    RR -->|git pull| WD

    style SA fill:#4a9ede,color:#fff
Key: You edit files in your working directory. You stage the changes you want to save. You commit them with a message. You push them to a remote repository (like GitHub) to share with others or back up. You pull to get changes others have made.

How does it work?

Repositories — your project’s memory

A repository (or “repo”) is a project folder that Git is tracking. It contains your files plus a hidden .git folder that stores the complete history of every change ever made. This history is the repository’s memory — it knows what every file looked like at every point in time.²

There are two kinds of repository:

Type	Where it lives	What it does
Local	On your computer	Where you work and commit changes
Remote	On a server (GitHub, GitLab)	Where you share, collaborate, and back up

You always work in your local repository. When you are ready to share or save to the cloud, you push to the remote. When you want to get someone else’s changes, you pull from the remote.

Commits — checkpoints with context

A commit is a snapshot of your project at a specific moment. It is not just a record of what changed — it is a complete picture of every tracked file’s state at that point.⁵

Every commit has:

A unique identifier (a hash like a3f7c2e) — its address in history
A message — a short description of what changed and why
A timestamp — when it was made
A parent — which commit came before it (creating a chain of history)

The commit message is the most important part for humans. A good message captures why a change was made, not just what changed. “Fix login bug where users were redirected to a 404” is useful. “Fixed stuff” is not.⁶

Think of it like...

A commit is like a save point in a video game. You can play forward from any save point, and if something goes wrong, you can reload an earlier save. The commit message is the label on the save slot: “Before fighting the dragon” is more useful than “Save 47.”

The staging area — choosing what to save

Git introduces a concept that most other tools skip: the staging area (also called the “index”). Before a change becomes a commit, you must explicitly stage it — telling Git “I want this specific change included in the next snapshot.”⁷

graph TD
    E[Edit files] --> S{Stage changes?}
    S -->|git add file.txt| SA[Staging Area]
    S -->|not yet| E
    SA -->|git commit| C[New Commit]

    style SA fill:#4a9ede,color:#fff

This might seem like an unnecessary extra step, but it is powerful. You might have changed five files, but only three of those changes are related to the current task. The staging area lets you commit just those three, keeping the other two for a separate commit. This produces a clean, readable history where each commit represents one logical change.⁷

Branches — parallel realities

A branch is a parallel version of your project where you can make changes without affecting the main version. Think of it as a copy that Git manages for you — lightweight, instant, and easy to merge back when you are done.⁵

graph LR
    M1[Main] --> M2[Main]
    M2 --> M3[Main]
    M2 --> F1[Feature Branch]
    F1 --> F2[Feature Branch]
    F2 -->|merge| M3

    style F1 fill:#5cb85c,color:#fff
    style F2 fill:#5cb85c,color:#fff

The default branch is usually called main. When you want to build a new feature, fix a bug, or try an experiment, you create a new branch. All your changes happen on that branch. The main branch stays untouched. When the feature is ready and tested, you merge it back into main.⁵

Branches are essential for AI-assisted development. When an AI tool generates a large block of code, creating a branch first means you can review and test the changes in isolation. If the AI-generated code breaks something, you delete the branch and main is unaffected.⁴

Example: branch workflow (click to expand)

You are working on a website. Main branch is stable and live.

You want to add a contact form. You create a branch called add-contact-form.

You (or your AI assistant) build the form on this branch. Several commits along the way.

You test it. It works. You merge add-contact-form into main.

You want to try a new colour scheme. You create experiment-colours. It looks terrible. You delete the branch. Main is unaffected.

Git vs GitHub

This distinction trips up every beginner: Git and GitHub are not the same thing.⁸

	Git	GitHub
What it is	A version control tool	A cloud platform built around Git
Where it runs	On your computer	On the internet
What it does	Tracks changes locally	Hosts repositories, enables collaboration, adds CI/CD, issue tracking, pull requests
Alternatives	None — Git is the standard	GitLab, Bitbucket, Codeberg
Cost	Free, open-source	Free tier + paid plans

Git is the engine. GitHub is the vehicle built around that engine.⁸ You can use Git without GitHub (many people do, for private or local projects). But you cannot use GitHub without Git — every operation on GitHub is a Git operation underneath.

Pull requests are a GitHub (not Git) concept: a way to propose changes from a branch, have them reviewed by others, and merge them into main only after approval. This is the standard collaboration workflow for teams of any size.

Why do we use it?

Key reasons

1. You can always go back. Made a mistake? Revert to the last working commit. An AI tool generated code that broke everything? Roll back in seconds. Without Git, “undo” is limited to Ctrl+Z in a single file. With Git, undo works across your entire project, across days, weeks, or months.⁴

2. You can work on multiple things in parallel. Branches let you experiment without risk. Try a new approach on a branch. If it works, merge it. If it does not, delete it. Main stays clean and deployable at all times.⁵

3. You can collaborate without chaos. Multiple people (or multiple AI assistants) can work on the same project simultaneously. Git tracks who changed what and when, and provides tools to merge changes together — even when two people edited the same file.³

4. You have a complete audit trail. Every commit is a record of what changed, when, why, and by whom. This history is invaluable for debugging, compliance, and understanding how a project evolved. When building with AI, commit messages capture the intent that the AI cannot infer.⁶

When do we use it?

When building any software project, regardless of size — even a personal website benefits from version control
When collaborating with others on the same codebase
When building with AI tools (Claude Code, Cursor, Copilot) — Git is your safety net for AI-generated code
When you need to track what changed and why over time
When you want to experiment without risking your working version
When deploying a website — most hosting platforms (Vercel, Netlify, GitHub Pages) deploy directly from a Git repository

Rule of thumb

If your project has more than one file and will last more than one day, use Git. The five minutes it takes to initialise a repository will save you hours of “which version was working?” later.

How can I think about it?

The time machine analogy

Git is a time machine for your project. Every commit is a moment in time you can travel back to. The timeline branches when you create a new branch — like alternate realities in a science fiction film. You can explore one timeline (a new feature), decide you prefer the other (the stable main), and collapse the timelines back together (merge) when ready.

Commit = a moment in time you can revisit

Branch = an alternate timeline

Merge = combining two timelines into one

Revert = travelling back in time

Log = the timeline’s history book

Remote = a backup of the timeline in another location

The notebook analogy

Imagine a shared notebook where every page is written in pencil. Without Git, everyone writes on the same pages and erases each other’s work. With Git, each person gets their own transparent overlay. They write their changes on the overlay (branch). When they are done, they carefully transfer their additions to the master notebook (merge). If two people changed the same line, Git flags it (merge conflict) and asks a human to decide which version to keep.

Notebook = repository

Writing on a page = editing a file

Transparent overlay = branch

Transferring to the master notebook = merging

Flagging conflicting edits = merge conflict

The pencil marks you can still see = commit history

Concepts to explore next

Concept	What it covers	Status
github	The cloud platform for hosting Git repositories, collaboration, and deployment	stub
branches	How to work in parallel and merge changes safely	stub
merge-conflicts	What happens when two changes collide and how to resolve them	stub
iterative-development	The build-test-learn cycle that Git enables through safe experimentation	complete
vibe-coding	AI-assisted development where Git is your safety net	complete

Some of these cards don't exist yet

They’ll be created as the knowledge system grows. A broken link is a placeholder for future learning, not an error.

Check your understanding

Test yourself (click to expand)

Explain what a commit is and why the commit message matters more than the code diff.

Describe the four-step Git workflow (edit, stage, commit, push) and explain why the staging area exists as a separate step.

Distinguish between Git and GitHub. Could you use Git without GitHub? Could you use GitHub without Git?

Interpret this scenario: you ask an AI assistant to refactor a large section of your codebase. It generates 200 lines of new code across 8 files. Before running the AI, you did not create a branch or commit your current work. The refactored code has a subtle bug. Using what you have learned, explain what went wrong and what you should have done differently.

Connect Git to iterative-development. How do branches and commits enable the build-test-learn cycle?

Where this concept fits

Position in the knowledge graph
graph TD
    SD[Software Development] --> GIT[Git]
    GIT --> GH[GitHub]
    GIT --> BR[Branches]
    GIT --> MC[Merge Conflicts]
    GIT -.->|enables| ID[Iterative Development]
    GIT -.->|safety net for| VC[Vibe Coding]
    style GIT fill:#4a9ede,color:#fff
Related concepts:

iterative-development — Git’s branching and committing model is the mechanism that makes iterative cycles safe and reversible

vibe-coding — when AI writes the code, Git provides the safety net to review, test, and roll back

architecture-decision-records — commit messages and ADRs together capture the “why” behind a project’s evolution

Explorer

Git

Git

What is it?

At a glance

How does it work?

Repositories — your project’s memory

Commits — checkpoints with context

The staging area — choosing what to save

Branches — parallel realities

Git vs GitHub

Why do we use it?

When do we use it?

How can I think about it?

Concepts to explore next

Check your understanding

Where this concept fits

Sources

Further reading

Graph View

Table of Contents

Explorer

Git

Git

What is it?

At a glance

How does it work?

Repositories — your project’s memory

Commits — checkpoints with context

The staging area — choosing what to save

Branches — parallel realities

Git vs GitHub

Why do we use it?

When do we use it?

How can I think about it?

Concepts to explore next

Check your understanding

Where this concept fits

Sources

Further reading

Footnotes

Graph View

Table of Contents