Somewhere on your laptop right now, there is a folder with real work in it. Maybe it is called python-practice. Maybe it is called project-FINAL-v2-USE-THIS-ONE. Maybe it lives in Downloads, which is where ambition goes to die.
That folder might contain weeks of effort. But from the outside? It is invisible. A hiring manager cannot see it. A collaborator cannot trust it. Future-you will open it in six months and wonder what any of it means.
Git fixes all of that. Not by making your code better — but by making your process visible.
What Git actually is (and is not)
Think of Git as a journal for your project. Every time you reach a meaningful point — fixed a bug, added a feature, got something working at 2 a.m. — you write an entry. That entry is called a commit. It records what changed, when, and why.
Now imagine you could flip back to any page in that journal and your entire project would rewind to exactly that state. That is Git. A time machine with better naming conventions.
Git vs. GitHub — they are not the same thing.
Git is the engine. It runs on your computer and tracks your project’s history. GitHub is a website that hosts your Git history online so other people can see it. Git works perfectly without GitHub. GitHub is where your Git history becomes a public asset.
Think of it this way: Git is the camera. GitHub is the gallery.
The glossary nobody gives you first
Most Git tutorials fail because they throw commands at you before you know what the commands touch. Here is the plain-English map. Tape it to your wall if you need to.
Git is four rooms, not one magic spell
Here is where most people get confused. They think Git is one thing. It is actually four spaces, and your files move through them like luggage through an airport.
The airport analogy. Your project files start in the working directory (the parking lot — you are still editing). When you are ready, you move them to the staging area (the check-in counter — you are choosing what to send). Then you commit (the flight departs — it is in the local history). Finally, you push to GitHub (the luggage arrives at the destination — now everyone can see it).
- Working directory — your actual project folder. Edit freely here. Nothing is tracked yet.
- Staging area — the draft tray. You pick which changes are ready for the next snapshot.
- Local repository — your commit history, stored in a hidden
.gitfolder on your machine. - Remote repository — the GitHub copy. Public, shareable, and inspectable by anyone you give access to.
Once you see these four rooms, the commands become ordinary verbs: inspect the working directory, add changes to staging, commit them to history, push that history to the remote. That is the whole workflow.
The workflow, slow and clear
Let us walk through the entire process. You have a folder with a Python script called hello.py. You want to track it with Git and eventually put it on GitHub. Here is every step.
1. Turn your folder into a Git repo
This creates a hidden .git directory inside your folder. That hidden directory is where Git stores everything. You will never need to open it — just know it exists. Your folder is now a repository.
2. Check what Git sees
This is the command you will run most often. It tells you what has changed, what is staged, and what is ready to commit. Think of it as asking Git, “What is going on right now?” Run it early, run it often, run it when confused. It never hurts.
3. Stage your file
This moves hello.py into the staging area. You are saying: “Include this in the next snapshot.” You can stage one file, three files, or everything — you choose. This is the check-in counter.
4. Commit — take the snapshot
Done. Your staged changes are now saved in the project timeline with a message that explains what you did. That message matters — it is a note to future-you and anyone who reads your history. “fixed stuff” is a crime. “Add input validation to login form” is a gift.
The Polaroid analogy. Each commit is a Polaroid of your project. You can take as many as you want. You can always go back and look at any one. But unlike a Polaroid, you can also restore your project to the exact state in that snapshot. It is a time machine disguised as a save button.
5. Check again
That clean status message is the most satisfying sentence in programming. Everything is saved. Everything is tracked. You can close your laptop and walk away knowing nothing is lost.
Branches: the safety net you did not know you needed
Here is a scenario. You have a working script. It does what it is supposed to do. Now you want to add a new feature, but you are not sure it will work. Do you edit the working version directly and pray?
No. You create a branch.
The notebook analogy. Imagine your project is a notebook with clean, finished pages. A branch is a loose sheet of scratch paper clipped to the side. You can scribble, experiment, cross things out — and if it works, you copy it into the notebook. If it does not work, you throw the scratch paper away. The notebook never got messy.
That is it. You experimented safely, and when the experiment worked, you folded it into the main timeline. Professional developers do this dozens of times a day. It is not advanced — it is just the habit of not gambling with working code.
Publishing to GitHub: making invisible work visible
Up to this point, everything lives on your computer. That is already valuable — you have a recoverable history and you can undo mistakes. But it is still invisible to the world.
To make it public, you connect your local repo to a GitHub repository and push.
Refresh the GitHub page. Your files, your commit history, your branch structure — all of it is now visible to anyone with the link. What was a private folder is now a public portfolio.
This is the shift that matters. A GitHub repo does not just store code. It answers questions before they are asked. Can this person write clean code? Are their changes organized? Do they work in branches? Do their commit messages make sense? A good repo is a silent interview that runs 24/7.
The command cheat sheet
You do not need to memorize these. Bookmark this page and come back when you need one.
| What you want to do | Command | Plain English |
|---|---|---|
| Start tracking a folder | git init | Create Git’s history storage inside this folder. |
| Check the situation | git status | What changed? What is staged? What is committed? |
| Stage one file | git add file.py | Put this file in the next snapshot draft. |
| Stage everything | git add . | Add all changed files. Use carefully. |
| Save a snapshot | git commit -m "msg" | Record staged changes with a short note. |
| Create a branch | git switch -c name | Start a new parallel timeline. |
| Switch branches | git switch main | Go back to the main timeline. |
| Merge work | git merge name | Fold a branch’s work into the current branch. |
| Connect to GitHub | git remote add origin URL | Tell Git where the remote lives. |
| Upload history | git push -u origin main | Send your commits to GitHub. |
| See commit history | git log --oneline | One-line summary of every snapshot. |
The mistakes everyone makes (and how to survive them)
“I typed get instead of git.”
The command is git. If your terminal says “command not found,” check spelling first. Then check if Git is installed. On Mac, typing git in Terminal usually triggers an install prompt. On Windows, download Git from git-scm.com.
“GitHub is asking for a login.”
That is normal when you push for the first time. You will need to authenticate — usually through a browser login, SSH key, or personal access token. It is a one-time setup that feels annoying and then never bothers you again. Like flossing.
“I committed the wrong file.”
Do not panic. Git is designed for recovery. The beginner-safe fix: make a new commit that corrects the mistake. Do not try to rewrite history on day one. That is surgery, and you are still learning to use a band-aid.
“My branch is called master, not main.”
Older repos use master as the default branch name. Newer ones use main. They work the same way. Run git branch to see what yours is called and use that name instead.
Do not let your work stay invisible
Here is the thing nobody tells beginners: the code itself is only half the story. The other half is proof that you built it thoughtfully. A clean Git history shows that you plan before you code, you isolate experiments from stable work, you write clear messages about what you did and why, and you ship incrementally instead of dumping everything at once.
That is not just good version control. That is how professionals work. And it starts with six commands:
One script. One repo. One commit. One push. That is your first step out of the final-final-v3 folder and into something people can actually see, trust, and respect.
The best time to start using Git was your first project. The second best time is right now.
— VJ
A note on how I write
I am not a writer. I am a person with strong opinions and scattered notes. Every essay on this site started as a messy brain-dump — half-formed arguments, bullet points, and “you know what I mean” — that I hand to an LLM. Another LLM handles the background research needed to find the facts that support an argument. And then it all gets translated into writing far too good for me to pretend is mine. The ideas are mine. The craft is not. They say blogs are dead — but I am falling in love with this. It gives me an outlet for expression that would otherwise have stayed buried in my head. I believe you deserve to know all of that.