The one idea
Git records changes over time, not copies.
A copy tells you a file existed. A commit tells you what changed, when, why, and lets you return to exactly that state. The difference is that history is searchable and copies are not.
Once you have history, "when did this break?" becomes a question with an answer.
It is an undo button that survives closing the file, remembers why you made each change, and lets you jump back to any past day.
Commits are labelled save points. Branches let you try something risky without touching what works. History tells you which change introduced a bug.
Git stores snapshots of the tree, addressed by content hash, linked into a directed acyclic graph. A branch is a movable pointer to a commit; nothing is copied when you create one.
Why _v2 fails
| Problem with copies | What Git does instead |
|---|---|
| You cannot tell what changed between v1 and v2 | git diff shows the exact lines |
| You do not know why v2 exists | Every commit carries a message explaining why |
| Two people editing produce v2 and v2-mine | Merging combines both sets of changes |
| Deleting old versions loses history | Old versions cost almost nothing and stay forever |
| You keep only the versions you thought to save | Every commit is a restore point |
The last row is the one that matters most. With copies you save when you remember to. With commits you save at every meaningful step, so the version you need later is almost always there.
The five commands that cover most days
You do not need forty commands. You need these, and you will use them in this order almost every time.
| Command | What it does |
|---|---|
git status | What has changed since the last commit. Run this constantly. |
git add <file> | Choose which changes go into the next commit |
git commit -m "message" | Save those changes with an explanation |
git log --oneline | See the history, newest first |
git diff | See exactly what changed, line by line |
Your first repository
1 of 5Turn a folder into a repository.
In the folder with your project, run
git init. This creates a hidden.gitfolder holding the history. Nothing else changes and no files move.Do this on the folder for a project, not on your entire Documents folder.
Branches: trying something without risk
A branch is a parallel line of work. Your working version stays untouched while you experiment on the branch. If the experiment works, you merge it back. If it does not, you delete the branch and nothing was lost.
git switch -c try-new-parser # create and move to a branch
... make changes, commit ...
git switch main # back to the working version, untouched
You want to rewrite how your project handles input, but the current version is what you demo on Friday. On a branch, you can attempt it, fail, and switch back in one second with the Friday version intact.
Without a branch, you either do not attempt it or you risk the demo. Most people choose not to attempt it, and that is the real cost.
Two people work on the same script. Each on a branch. Git combines both sets of changes, and where they edited the same lines it stops and asks a human to decide.
The alternative — emailing files and manually re-typing each other's edits — is how changes get silently lost.
When you have broken everything
Getting back to safety
1 of 5Stop and commit nothing yet.
Do not add more changes on top of a mess. Run
git statusand read what is actually modified. Often less is broken than it feels.
Try this
You committed and pushed a file containing a live API key to a public repository eleven minutes ago. What is your first action?
Your challenge
Level 3 · IndependentTake an existing project folder — even a small script — and put it under Git.
You have succeeded when you can, in front of someone: create a .gitignore and
explain each line, make three commits with messages that say why, create a
branch and make a change on it, switch back and show the change is gone, and
restore a file to a previous version.
Then break something deliberately and recover it using history rather than memory.
What people usually get wrong
- One giant commit at the end of the day. The point is granularity. Ten small commits give you ten restore points; one gives you one.
- Messages like "update", "fix", "asdf". In two months these are worthless. Say what changed and why.
- Committing secrets. Write
.gitignorebefore your first commit, not after the leak. - Committing generated files and dependencies. They bloat the repository and cause conflicts constantly. They can be regenerated; that is what makes them generated.
- Using
--forceon a shared branch to fix a mistake. It rewrites history other people are working on. Usegit revertinstead. - Not committing before a risky change. The commit is what makes the change reversible. Thirty seconds beforehand, hours saved after.
How someone experienced does it
Experienced developers commit far more often than beginners expect — several
times an hour, in small pieces that each do one thing. Not out of discipline: it
is what makes git bisect work, where Git walks the history testing each commit
until it finds the one that introduced a bug. That turns "somewhere in three
weeks of work" into an exact commit in about eight steps. It only works if your
commits are small.
They also treat the commit message as documentation for a stranger. The stranger is themselves, next year, with no memory of this week. "Handle blank amount rows — the finance export leaves them empty rather than zero" tells that stranger something they could not have worked out from the diff.
And they never rewrite shared history. Local history is yours to tidy. Anything another person has pulled is a fact about the world, and changing facts other people are standing on is how you lose an afternoon of everyone else's time.
Git versus GitHub, and what 'push' means
Git is a program on your computer. It works fully offline. Every commit, branch and restore in this lesson happens locally and needs no internet and no account.
GitHub, GitLab and Bitbucket are websites that host a copy of a Git repository. They add collaboration on top — issues, reviews, permissions — but the version control itself is Git.
git push sends your local commits to that hosted copy. git pull brings other
people's commits down. git clone makes a full local copy of a repository,
including its entire history.
Two consequences worth holding on to. First, you can use Git alone, privately, forever, and get every benefit in this lesson. Second, a clone contains all history — which is precisely why a committed secret is a real leak and not a theoretical one.
Prove it
Show git log --oneline for a real project of yours with at least eight commits
whose messages a stranger could follow.
Then demonstrate one recovery: restore a file to an earlier state, or revert a commit. The log proves the habit. The recovery proves you can use it when it matters.
Keep learning this
Paste this into any AI assistant. It turns the assistant into a tutor that tests you instead of just answering you.
Act as an experienced practitioner who is good at teaching. I have just learned using Git for version control as a beginner. Assume I am intelligent but relatively new to this — treat me as beginner level. Work through this in order, and wait for my reply at each step: 1. Ask me 5 questions that test whether I actually understood using Git for version control as a beginner. Do not reveal the answers yet. 2. After I answer, tell me which parts I got right, which I got wrong, and which I only half-understand. Explain only what I misunderstood — do not re-teach what I already know. 3. Give me one practical challenge based on something I could genuinely encounter at work or in daily life. Do not solve it for me. 4. Evaluate my solution the way an experienced person would judge it, including what a professional would have done differently. 5. Tell me what to learn next, and why that comes next. 6. Give me trustworthy sources for deeper study — prefer official documentation, primary research or standards bodies over blogs and videos. Rules for you: no buzzwords. No motivational filler. Say "I'm not certain" when you are not certain, and tell me which parts of your answer I should verify myself. Clearly separate facts from your recommendations and your opinions.
Become independent at this
Use this when you want a path from where you are to actually good, with checkpoints you can test yourself against.
I want to become independently capable at version control and never losing work — not permanently dependent on AI, tutorials or step-by-step guides. Design a progression for me with five stages: Beginner, Guided practice, Independent practice, Real-world application, Professional level. For each stage tell me: - what I must know - what I must be able to do without help - the mistakes people make at this stage - one practical challenge - one real project that would prove I reached this stage - one way I can test myself honestly Then tell me the signals that I am ready to move to the next stage, and the signals that I have skipped ahead too early. Keep the theory to the minimum I actually need. Focus on ability I can transfer to situations you and I have not discussed.