Snapshots with names

Every project you’ll ever work on changes. Files get edited, deleted, renamed, broken and fixed again. Git is the tool almost every software team uses to remember all of it. It can tell you what the project looked like last Tuesday, who changed this line, and give you back the version from before you broke it.

The idea underneath is simpler than its reputation:

1. You work on files as normal, in your working tree.
2. When you have something worth keeping, you put those changes in the staging area (git add).
3. Then you take a snapshot of everything staged (git commit). The snapshot is permanent, and it gets a name.

That name is the interesting part. Git doesn’t number snapshots 1, 2, 3. It runs the snapshot’s exact contents through a hash function called SHA-1 and uses the 40-character result as the name. Same contents, same name, on every computer in the world. Change one letter and you get a completely different name.

Your first commit

The playground below is a small git that runs entirely in your browser. It isn’t a recording: it stores files exactly the way real git does. Every hash you see is the hash real git would print for the same file, author and time. Follow the mission, and use hint if you get stuck.

Why staging exists

Beginners often ask why you can’t just commit straight away. Staging lets you choose what goes into a snapshot. Say you fixed a bug and also left some debugging junk lying around: you stage the fix, commit it, and the junk stays out of history. One commit should be one idea.

mkdir panda && cd panda
git init
echo "hello, panda" > hello.txt
git add hello.txt
git commit -m "my first commit"
git log
git hash-object hello.txt