1. Why version control exists

Version control answers one question: what did this project look like at any moment, and who changed what, when, and why? Without it you get train_final_v3_REALLY_final.py, lost work, and models nobody can rebuild.

The five problems it solves

1. Time travel. Return to any earlier known-good state, for one file or the whole project.
2. Attribution and intent. Every change records an author, a time and a message explaining why.
3. Parallel work. Several lines of development proceed at once without overwriting each other.
4. Integration. Parallel lines are combined, and the tool detects where they truly conflict.
5. Reproducibility. “Which exact code produced this model?” has an answer only if every state has a permanent name.

Every feature of Git exists to serve one of these five. When a feature confuses you, ask which problem it solves.

Two ways to record history: deltas or snapshots

A delta system stores the first version, then a chain of changes. To rebuild version 100, it replays 99 diffs. Older tools such as RCS and Subversion think this way.

A snapshot system stores the complete state of the project at each save. Unchanged files are not copied again; the new snapshot just points to the old content. Git works this way.

This is the most important correction to most people’s mental model: a commit is a snapshot, not a diff. When git show displays a diff, Git is comparing that snapshot with its parent on the fly. Git does compress similar files internally, but that is a storage trick you never see (Part 13).

Centralized versus distributed

In a centralized system one server holds the history, and your machine holds only a working copy. In a distributed system every clone is a full copy of the whole database.

Question	Centralized (Subversion, Perforce)	Distributed (Git, Mercurial)
Where does history live?	On the server only	In every clone
Is a commit a network operation?	Yes	No, it is purely local
What works offline?	Editing files	Commit, branch, log, diff, merge - everything except sharing
Cost of a branch	Often a server-side copy	One tiny file holding a hash
Backup	The server is a single point of failure	Every clone is a full backup

The consequence: in Git, recording a change (commit) and sharing it (push) are two separate acts. Most beginner confusion about “why isn’t my change on GitHub?” comes from merging these two in the head.

Git is not GitHub

Git is a program and a data format. GitHub, GitLab, Bitbucket, Codeberg and the Hugging Face Hub are hosting services that store Git repositories and add features on top.

Pull requests, issues, code review, CI pipelines, forks and access permissions belong to the host, not to Git. This matters when you search for answers: “how do I squash in a pull request” is a GitHub question; “how do I squash commits” is a Git question.

A little history that explains the design

Linus Torvalds wrote Git in 2005 to manage the Linux kernel, after the kernel lost free access to its previous tool, BitKeeper. The design goals were speed, data integrity, full distribution, and support for thousands of parallel branches.

Those goals explain Git’s shape. Integrity led to hashing every object. Speed led to local-only operations. Thousands of branches led to branches being nearly free.

Check yourself

• Why can you commit on a plane but not push?
• If a commit is a snapshot, where does the diff in git show come from?
• Name one feature you use on GitHub that Git itself does not have.