What Git Actually Is (and What It Is Not)
The previous topic ended with a list of requirements. This one names the program that meets them.
Git is a program on your computer that records the state of a folder every time you ask it to, and can put that folder back into any state it has recorded. That is the whole idea. Everything else in this book is vocabulary and safety rails built around that one sentence.
A photographer's contact sheet is a fair picture of it: every frame kept, in order, each with a caption saying what the shot was for. The negatives never change. You simply choose which frame to look at.
A program, not a service
Git runs on your machine. There is no account, no sign-up, and no server involved. You can use it on a plane with the wifi off, and everything in the first six chapters of this book works exactly the same with your network cable unplugged.
This surprises almost everyone who met GitHub first, which is most people. We will come back to that confusion at the end of this page, because clearing it up now saves a great deal of bewilderment in Chapter 7.
What it records
You do not tell Git "save this file". You tell it: record the project as it looks right now, and here is why. That recorded state is called a commit, and from here on we will use the real word.
A commit holds the project's files as they were at that moment, plus your name, the time, and the message you wrote. The message is the part that no other tool keeps and the part you will be most grateful for later.
The history is a chain
Each commit also remembers the commit that came before it. That single link is what turns a pile of saved states into a history with an order: this state, then this one, then this one.
Because the order is recorded rather than guessed from file dates, the project's past becomes something you can read from end to end — which is what Chapter 3 is about.
Three things Git is not
Git is not a backup service. The history lives inside the same folder, on the same disk, and it dies with the laptop. Git protects you from changes you regret; it does not protect you from a stolen bag. Chapter 7 adds a copy that lives somewhere else, and until then a Git repository on a dying machine is exactly as doomed as the machine.
Git is not a file-sharing tool. Nothing is uploaded, synchronized, or shared until you explicitly send it somewhere.
And Git is not GitHub. Git is this program, keeping history on your machine. GitHub is a company that stores copies of Git repositories on the internet and puts a website around them. You can use Git for years without GitHub; the reverse makes no sense at all. If you remember one distinction from this chapter, make it this one.
Why this particular program
Git is not the only version control system, and it is not obviously the friendliest. It won anyway: essentially every software project you will encounter uses it, which makes it the version control worth your first month. Mercurial, Subversion and Perforce exist and are perfectly real; this book names them here and never again.
- "Git and GitHub are the same thing." Git is the program keeping history on your machine. GitHub is one company hosting a copy of that history online. The first six chapters of this book use Git with no account of any kind.
- "Git backs up my work." It protects you from yourself — from a change you regret, a file you deleted, an idea that went wrong. It does nothing about a failed disk until a copy exists elsewhere, which is Chapter 7.
- "Git saves everything automatically as I type." Nothing is recorded until you ask. That is deliberate: an automatic snapshot would have no reason attached to it, and the reason is the whole point.
- "A commit saves one file." A commit records the project, not a file. You choose which changes go into it — that choice is Chapter 2 — but what gets stored is a state of the whole thing.
- The Git-is-not-GitHub distinction is the most common beginner confusion in this whole subject, and it is cheapest to fix now, before either one is installed.
- Knowing that Git is local explains why the next five chapters need no account, no network, and nobody's permission — which is also why they are a safe place to make mistakes.
- "Snapshot plus a link to the one before it" is the model that makes branches and merges in Chapter 6 feel obvious rather than magical.
Knowledge Check
Which of these still works with your machine completely offline?
- Recording a commit and reading the entire history of the project
- Nothing, because Git checks your account before it records anything
- Only reading old commits, because recording a new one has to be confirmed
- Only the very first commit, because later ones are stored on a remote server
In one sentence, what does a commit record?
- The state of the project at that moment, with the author, the time, and a message
- The individual keystrokes you typed since the previous commit was recorded
- A copy of the single file you were working on when you ran the command
- A note in a log file describing what you intended to change next
Your laptop is stolen and your project was only ever committed locally. What have you lost?
- Everything, because Git's history lives in the same folder on the same disk
- Nothing, because Git keeps an automatic online copy of every repository
- Only the most recent commits, because older history is archived off the machine
- Only the commit messages, because the file contents are recoverable from the disk
A classmate says "I'll learn GitHub, then Git later." What is wrong with that order?
- GitHub hosts copies of Git repositories, so it makes little sense without the tool underneath
- Nothing is wrong — GitHub is a completely separate tool that replaces Git entirely
- GitHub is much harder than Git, so starting there means starting with the difficult half
- Git is being retired, so learning it after GitHub means learning it too late to matter
You got correct