What is version control, and how does Git think?

Imagine editing a project for several weeks and keeping copies named final, final2 and final-really. Version control replaces that fragile habit with an intentional history of meaningful checkpoints.

A repository is a project plus Git's history and metadata. A commit records a project state together with author information, a message and links to parent commit(s). Git identifies objects with hashes.

Git is distributed: a normal clone contains project history, so many history operations do not need a network connection. Branch names are movable references to commits; HEAD normally identifies the branch or commit you currently have checked out.

Run this in a disposable practice repository unless the lesson explicitly says otherwise.

mkdir git-course-demo
cd git-course-demo
git init

git init creates Git metadata for the current folder. Your ordinary project files remain ordinary files; the hidden .git directory stores the repository's local metadata and object database.

Your task: Draw three commits as A → B → C. Add a branch name main pointing to C. Then imagine a second branch feature pointing to B. Explain that the branch names are labels pointing into the same commit graph.

A commit is not simply a copied folder with a sequential version number. Git stores objects efficiently and identifies content cryptographically. For beginners, the useful mental model is still 'a saved project snapshot connected to previous snapshots.'

What is version control, and how does Git think? is complete when you can explain the state being changed before you run the command, not merely repeat the syntax.

Read further: official supporting documentation.