Every step below uses the same commands you would use with code. The example is a short artist statement being written and revised. Follow along — the file is called statement.txt.
1 — Start tracking the folder
$ git init
Initialized empty Git repository in /artist-statement/.git/
2 — Write a first paragraph. Stage it. Commit it.
statement.txt
My work explores the relationship between memory and place.
I collect fragments — receipts, photographs, recorded voicemail —
and reassemble them into structures that resist easy narrative.
$ git add statement.txt
$ git commit -m "first paragraph — memory and place"
git add is required here because statement.txt is a brand new file — git has never seen it before and won't track it automatically. Once a file has been added, you don't need to git add it again for future changes.
3 — Write a second paragraph. Commit again.
statement.txt
My work explores the relationship between memory and place.
I collect fragments — receipts, photographs, recorded voicemail —
and reassemble them into structures that resist easy narrative.
The browser is my primary medium. I am drawn to the web because
it is simultaneously public and intimate, permanent and ephemeral.
$ git commit -am "add second paragraph — browser as medium"
The -a flag stages all changes to already-tracked files automatically. No separate git add needed.
4 — Try a different direction. Rewrite paragraph 1. Commit that too.
statement.txt
My work is interested in systems that forget. GPS coordinates
that drift. Timestamps that contradict. I build things that
fail in precise ways.
The browser is my primary medium. I am drawn to the web because
it is simultaneously public and intimate, permanent and ephemeral.
$ git commit -am "rewrite paragraph 1 — shift to systems that forget"
Three ways to stage — same result, different control:
git add statement.txt — stage one specific file. Required the first time a new file is added.
git add . — stage everything that has changed. Useful when you have multiple files and want to commit all of them.
git commit -am "message" — skip the staging step entirely for already-tracked files. Fastest option for a single ongoing file.
5 — Look at your history
$ git log --oneline
a3f7c29 rewrite paragraph 1 — shift to systems that forget
8b1d4a1 add second paragraph — browser as medium
f2c3d11 first paragraph — memory and place
Three snapshots. Each one a decision.
6 — See exactly what changed in the last commit
$ git diff HEAD~1
- My work explores the relationship between memory and place.
- I collect fragments — receipts, photographs, recorded voicemail —
- and reassemble them into structures that resist easy narrative.
+ My work is interested in systems that forget. GPS coordinates
+ that drift. Timestamps that contradict. I build things that
+ fail in precise ways.
Lines beginning with - were removed. Lines beginning with + were added. HEAD~1 means "the commit just before the current one."
7 — The rewrite isn't working. Go back to the previous version.
You want to return to the state after Step 3 — both paragraphs, original first paragraph. Copy the hash from git log:
$ git checkout 8b1d4a1
statement.txt now reads:
My work explores the relationship between memory and place.
I collect fragments — receipts, photographs, recorded voicemail —
and reassemble them into structures that resist easy narrative.
The browser is my primary medium. I am drawn to the web because
it is simultaneously public and intimate, permanent and ephemeral.
The rewrite commit still exists in the history — nothing was deleted.
8 — Come back to the present
$ git checkout main
You are back at the most recent commit. All three commits are intact. You can go back and forward as many times as you like.
9 — Push to GitHub
All of the above happened locally — only on your computer. To send your commits to GitHub, you push. The first time, you need to tell git where to send them:
$ git remote add origin https://github.com/yourname/artist-statement.git
$ git push -u origin main
After that first setup, every subsequent push is just:
$ git push
In VS Code, the first push appears as a Publish Branch button in the Source Control panel — it handles the setup automatically.
The point: Git didn't protect you from making a bad revision — it protected you from being stuck with it. Push gets that history off your machine and onto GitHub — backed up, shareable, and visible as a portfolio of your process.
Walk through this live in class with a plain text file open in VS Code. Key moments to pause: after git log (have students read the three commit messages aloud — does the history tell the story?), after git diff (the +/- format is unfamiliar but immediately readable once you see it), and after git checkout (show that the file literally changes in the editor window). The return to main reassures students that going back is always reversible.
