What Git Actually Is (and Isn't)

1The problem before the tool

Picture a client proposal sitting on a shared drive. Someone drafts it as proposal.docx. Someone else adds pricing and saves it as proposal_v2.docx. A third person fixes a typo and, not sure which version is current, saves proposal_v2_FINAL.docx. A week later a client calls about a number that turns out to belong to neither file: it was typed into a copy nobody renamed at all, now sitting three folders away, and the only way to find it was to remember who had it open last Tuesday.

Nothing about that process was careless. It is simply what happens when a tool is asked to track change and was never built to. The filename is doing a job it cannot do: saying what changed, when, and why, across everyone who touched the file.

2What git actually is

Git is a program that runs on your own computer and watches one folder, called a repository, or repo for short. This folder you are reading these notes from, HN - Training, is a repository. Inside it sits an ordinary folder named .git that most file browsers hide by default. That hidden folder is the entire history. Delete every other file in the project and keep only .git, and nothing is lost. Delete .git and keep everything else, and the history is gone, though the current files remain.

When you decide a change is worth keeping, you tell git to record it. That record is called a commit, and a commit is a complete snapshot of every file in the project at that moment, not a description of what changed. Git works out the difference between two snapshots whenever you ask it to show you one, which is why it can tell you exactly what changed in any file between any two points in the project's life, including files nobody has opened in years.

Line the snapshots up in the order they were made and you get the project's history. Section 4 reads this training site's real history, five commits long so far, so the idea has a concrete example before the next session adds GitHub to it.

3What git is not

4Five real commits

This is the actual history of the repository you are reading right now, oldest first, exactly as git reports it:

Each short hash is the first seven characters of a much longer fingerprint git calculates from the snapshot's contents. Two different snapshots never produce the same hash, so the hash is also how git tells commits apart and refers to one exactly, the way a check number refers to one payment. Each message is one line the person who made the commit wrote, by hand, to say what that snapshot changed. Session 03 covers what makes a message like "Library view on mobile" more useful six months from now than one like "fix stuff".

5Why this is worth 45 minutes

You do not need to become a software engineer to get real value from this. Anyone who edits this training site, or any future project kept the same way, gets three things from the habit: a change that goes wrong can be pointed at and undone, because the snapshot before it still exists; two people can work on the same project without emailing files back and forth, because branches, in session 04, give each person their own line of work; and a change to something as sensitive as a page that is only supposed to be visible to Hermetic staff is recorded, with a name and a timestamp attached, which matters the moment something needs to be traced back.

6Try it: read, don't write

Everything in this lab only reads the repository. None of it changes a single file, so there is nothing to undo and nothing to be careful about. Open a terminal in the HN - Training folder and run each of these in order.

1. Run git log --oneline. Confirm you see the same five lines as the table in section 4, in the same order, newest at the top.
2. Run git log -1 --stat. This shows the single most recent commit and which files it touched. Name one file it changed.
3. Run git show 10cdf79 (or whatever the first hash is by the time you try this). Git shows you that entire commit. Scroll to the top and find the author line and the date.
4. Run git status. If nothing is in the middle of being changed, git reports a clean working tree. Keep that phrase in mind; session 03 uses it constantly.

7Check for understanding

1. A technician keeps three files named report.docx, report_v2.docx and report_final.docx on a shared drive. What does git replace this pattern with?

   A.A convention for naming each version more consistently, such as report_2026-10-01.docx. B.One file with one name, with every earlier version kept as a snapshot in the project's history instead of as a separate file. C.A rule that only the newest version of a file is ever kept, so there is nothing left to confuse. D.Automatic cloud sync, so every save is instantly shared with everyone who has the drive open.
   Answer

   Git keeps one file under one name. What changes is that every version that file has held is kept as a snapshot in the project's history, reachable on request, rather than kept or lost depending on who remembered to save a copy.

   Show the answer
2. What does a git commit actually record?

   A.A line-by-line description of what changed since the last commit. B.A short message only, with the actual files left wherever they were. C.A complete snapshot of every file in the repository at that moment. D.Confirmation that every file in the project changed since the last commit.
   Answer

   A commit is a complete snapshot: every file in the repository as it stood at that instant, whether or not that particular file changed since the last commit. Git works out any difference you ask to see afterward, by comparing two snapshots.

   Show the answer
3. Priya edits three files in HN - Training this afternoon but never runs a git command. What does the repository's history show tomorrow?

   A.Three new commits, one per file she touched. B.One commit covering all three files, made automatically at the end of the day. C.No new commit. The files are changed on disk, but the history has nothing until she commits. D.Her edits are discarded, since git only keeps changes that are committed the same day they are made.
   Answer

   Git does nothing on its own. Priya's edits exist on disk, and git can see that something has changed if she runs git status, but no commit exists, and no history entry exists, until she deliberately records one. Session 03 is this exact habit.

   Show the answer
4. Why does deleting the hidden .git folder destroy a repository's history, when all the visible files are untouched?

   A..git only marks the folder as a repository; the real history is stored on GitHub, so nothing local is actually lost. B..git holds every commit ever made. The visible files are only today's snapshot, and the history exists nowhere else unless it was pushed to a remote. C..git keeps a second hidden copy of every file, so deleting it only removes a redundant backup. D..git stores temporary files only; the visible files are rebuilt from a separate source each morning.
   Answer

   .git is not a label or a convenience copy. It is the actual storage for every commit the repository has ever recorded. The files you can see in the folder are only the current snapshot, checked out for you to work with. Delete .git and the history is gone unless a copy of it exists somewhere else, such as on GitHub, which session 02 covers.

   Show the answer
5. A commit message reads "fix stuff". What is the actual cost of a message like this?

   A.The commit fails to save, since git requires a minimum message length. B.Nothing is lost from the snapshot itself, but anyone reading the history later, including you, has no way to tell what that commit was for without reopening it. C.Git only records half the changed files when the message is too short. D.The message gets emailed automatically to everyone with access to the repository.
   Answer

   The snapshot itself is unaffected. What a vague message costs is readability later: six months from now, "fix stuff" tells nobody, including the person who wrote it, what that commit actually changed or why, which means they have to open the full commit just to find out. Session 03 covers what a message should say instead.

   Show the answer

8Before session 02

• Run the four commands in section 6 and keep the output; session 02 picks up from the same repository.
• Create the practice folder described in the aside in section 6, outside both HN - Training and any OneDrive folder, and confirm git init ran without an error.
• Notice, next time you open this training site in a browser, that you had to sign in. Session 02 is about what makes that happen and what it has to do with git.

9Glossary

Version control

Software that records a project's history over time so any earlier state can be found again.

Repository (repo)

A folder git is tracking, made of the current files plus a hidden .git folder holding the full history.

Commit

A recorded snapshot of every file in the repository at one moment, with an author, a timestamp and a message.

Hash

The fingerprint git calculates from a snapshot's contents, used to refer to that exact commit. The short hash is its first seven characters.

History

Every commit a repository has, in order, each one still reachable.

Working tree

The actual files on disk right now, as opposed to any past snapshot of them.

Clean working tree

The state git reports when nothing in the working tree differs from the most recent commit.

10Sources

• Scott Chacon and Ben Straub, Pro Git, 2nd edition, chapter 1, "Getting Started", on what version control is and what git adds to it. Free to read online.
• GitHub, What is GitHub?, for how the next session's tool fits in.
• Commit history is from this repository, HN - Training, read with git log on 2026-10-03.