Why History Matters
Git commands are easy to copy and hard to trust until you know what history is for. This lesson builds that model: a snapshot is a decision you chose to keep, copies are not a timeline, and collaboration needs a shared record—not a pile of files named final.
Build the mental model before the first command
History is a record of decisions
Software work is a sequence of choices: this heading, that function, this file ignored, that bug fixed. The latest folder on disk only shows the current choice. It does not show what you tried, what you reverted, or why the current text won.
A history answers three questions a current copy cannot: what the project looked like at a chosen moment, how it differed from the moment before, and why someone kept that difference. Git will later store those answers as commits. This lesson is about needing the answers at all.
Copies and backups are not a timeline
When history is missing, people invent it with filenames. The folder below is familiar because it feels safe. It is not a history. Nothing records which file came from which, what changed between them, or which copy a teammate should open.
Desktop/
notes.txt
notes-final.txt
notes-final-v2.txt
notes-USE-THIS.txt
notes-from-sam.zipIdentity lives in the filename
- Each copy is a new object with a new name.
- You cannot ask what changed between v2 and USE-THIS.
- Two people can each have a different “final”.
- Deleting a copy destroys that state forever.
Identity lives in the timeline
- The project keeps one working name, such as
notes.txt. - Earlier states remain addressable after the file moves on.
- A later reader can compare two states without guessing.
- A message can explain the decision, not only the bytes.
A backup is still useful. If a laptop dies, you want a disaster copy of machines and data Git should never store: secrets, entire disks, downloads, and private media. Backup answers “can I restore the machine?” History answers “can I explain this project’s past?” Do not force one tool to do both jobs.
A snapshot must keep more than the latest text
Imagine a README that grew in three deliberate steps. A useful record looks like a chain, not a pile. Each step has a parent, a complete project state, and a sentence about intent.
c1Start the project READMEThe first kept state. Later snapshots are meaningful only because this one exists.
c2Add a troubleshooting sectionThe difference from c1 is the new section. The rest of the file is still part of this snapshot.
c3Explain why the heading changedThe latest state. c1 and c2 remain available; they were not renamed into oblivion.
c3 Explain why the heading changed
c2 Add a troubleshooting section
c1 Start the project READMENotice what the log preserves: order, completeness, and intent. It does not yet mention branches, remotes, or GitHub. Those are later tools for moving and reviewing this kind of record. If the record itself is not worth keeping, no hosting site will save the project from confusion.
Must be reconstructable
From any kept snapshot you should be able to restore the project files as they were, not a vague memory of them.
Must be comparable
Two snapshots should differ in a reviewable way: added lines, removed lines, and renamed paths—not a new mystery filename.
Must be attributable
Someone made the change. History that cannot say who is weaker when a team later asks what happened.
Must carry intent
A sentence such as “fix the broken heading” is part of the record. Bytes without a reason rot into archaeology.
Collaboration needs a shared previous state
Two people editing the same project without a shared timeline are not collaborating. They are producing two presents. When those presents meet, nobody can tell which lines are new, which lines were already agreed, and which lines conflict.
A shared history gives each change a parent. “I started from snapshot c2” is a fact another person can verify. Emailing notes-from-sam.zip is not that fact. GitHub pull requests will later make the conversation visible; they still depend on this model. A review comment is only useful if both people are looking at the same recorded difference.
The questions later lessons will answer
This course exists so those questions get precise tools. You do not need the commands today. You do need the jobs:
- 01Record a snapshot
How do you keep a complete project state with a message? Later:
addandcommit. - 02Inspect the past
How do you read what changed and why? Later:
status,log,diff, andshow. - 03Integrate lines of work
How do two histories meet without destroying either? Later: branches, merge, rebase, and conflicts.
- 04Share and review
How does a team agree on the next snapshot? Later: remotes, GitHub, pull requests, and checks.
Worked example: one file, two stories
A learner writes a README, then changes the title, then adds a setup section. Story A uses copies. Story B uses snapshots. Predict which story can answer “what did the title used to be, and why did it change?”
Three files, no parent
README.txt— current titleREADME-old.txt— maybe the first titleREADME-setup.txt— maybe only the new section
One file, three snapshots
- c1 records the first title
- c2 records the title change and the reason
- c3 records the setup section on top of c2
Story B can restore c1, compare c1 to c2, and read the message on c2. Story A can only open whichever file still exists and guess. That is the entire lesson, applied to one README.
Test what you learned
Which word should describe a complete project state you chose to keep: copy, backup, or snapshot?
Independent lab: write a four-step history
Do this on paper or in a notes file—not in Git yet. Pick a tiny project you actually have: a homework file, a personal README, or a recipe. Write four snapshots as a table with these columns: number, what the files contained, what you changed from the previous snapshot, and why you kept that change.
Then answer, in one sentence each:
- Which snapshot would you restore if today’s version was a mistake?
- Which two snapshots would you compare to explain a disagreement with a teammate?
- Which filename copies would you delete if this table were the real record?
Test what you learned
If the latest files are wrong, what must already exist for you to restore an earlier complete state?
Common beginner mistakes—and the better question
“I saved the file, so I have history.”
Saving replaces the working copy. Ask: can I restore last Thursday’s complete project?
“I zipped the folder every Friday.”
That is a backup cadence. Ask: can I compare Friday’s zip to Wednesday’s change and read why it happened?
“GitHub is version control.”
GitHub hosts and reviews Git history. Ask: what local record would still exist if the website were down?
“I will learn commands first.”
Commands implement jobs. Ask: which job—record, inspect, integrate, or share—am I trying to do?
Lesson review
You now have the orientation the rest of the Git course depends on. A current copy is not a history. A backup is not a timeline. A snapshot is a complete state you chose to keep, with enough identity, comparison, and intent to reconstruct a decision. Collaboration requires that shared record. Later lessons teach Git and GitHub as tools for making this record precise, not as a replacement for thinking.
- I can explain the difference between saving, backing up, and recording a snapshot.
- I can say why filename copies fail as a timeline.
- I can name what a useful snapshot must preserve: completeness, comparison, attribution, and intent.
- I can explain why two people need a shared previous state before they merge work.
- I know the next published lesson will turn this model into Git’s vocabulary of snapshots and graphs.