Version Control with Git: The Basics

Why version control exists

Have you ever saved a file as essay_final.doc, then essay_final_v2.doc, then essay_FINAL_really.doc? That messy trail is a homemade, error-prone version control system. Git does the same job properly: it records snapshots of your whole project over time, so you can see what changed, when, and why — and rewind to any earlier point if something breaks.

Git is the tool nearly every professional developer uses. Unlike most lessons here, this one is about commands you type in a terminal rather than program code, but the ideas are just as practical. Once you understand the workflow, it becomes second nature.

Repositories: where history lives

A repository (or repo) is simply a project folder that Git is watching. To turn an ordinary folder into a repo, you run one command inside it:

git init

This creates a hidden .git folder where Git quietly stores the entire history. Your normal files look unchanged; the magic happens in that hidden database. You only run git init once per project.

Before Git can record who made changes, tell it your name and email (a one-time setup on a new machine):

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

The three areas

The key to understanding Git is picturing three places a file can be:

1. Working directory — your actual files, where you edit and experiment.
2. Staging area — a holding zone where you gather the changes you want to save next.
3. Repository (history) — the permanent record of saved snapshots, called commits.

Work flows in one direction: you edit in the working directory, stage the changes you're happy with, then commit them into history. The staging area in the middle is what lets you save changes in clean, deliberate batches rather than all at once.

Checking the state with git status

Before doing anything, it's good habit to ask Git what it sees:

git status

Git replies in plain English: which files are new and untracked, which are changed but not yet staged, and which are staged and ready to commit. You'll run git status constantly — think of it as Git's "where am I?" button.

Staging changes with git add

Suppose you've created a file called notes.txt. To move it into the staging area, ready for the next snapshot, you use git add:

git add notes.txt

This tells Git "include this version of notes.txt in my next commit." You can stage several files, or stage everything that changed at once with a dot:

git add .

The dot means "all changes in this folder." Importantly, git add does not save a permanent snapshot yet — it only prepares one. Nothing is locked into history until you commit.

Saving a snapshot with git commit

A commit is a permanent snapshot of everything currently staged. Every commit needs a message describing what changed:

git commit -m "Add project notes file"

Breaking that down:

• git commit records the staged changes into history.
• -m means "the message follows."
• The text in quotes is your message. Write it clearly and in the present tense, like a short instruction: "Add login button," "Fix spelling in README." Six months from now, these messages are how you (or a teammate) understand the history.

After committing, your staging area is empty again, ready for the next batch of changes.

Viewing history with git log

To see every commit you've made, newest first, run:

git log

Each entry shows a long unique id (a hash), the author, the date, and the message. A tidier one-line view is often more useful:

git log --oneline

This shows a compact list — one short id and message per line — giving you a quick overview of the whole project's story.

A complete first workflow

Here's the full cycle from empty folder to first saved snapshot. Each line is a command you'd type in the terminal:

# 1. Start a repository in the current folder
git init

# 2. Create a file (here using echo, but any editor works)
echo "My first project" > readme.txt

# 3. See what Git notices
git status

# 4. Stage the new file
git add readme.txt

# 5. Save the snapshot with a clear message
git commit -m "Add readme with project title"

# 6. Confirm it worked
git log --oneline

Walking through it:

1. git init turns the folder into a repo.
2. We create readme.txt. (echo "..." > file writes that text into a file.)
3. git status now reports readme.txt as untracked — Git sees it but isn't recording it yet.
4. git add readme.txt stages it.
5. git commit permanently records it with the message.
6. git log --oneline shows your single commit — your project now has a history.

Repeat steps 3–6 every time you make meaningful progress. Edit, status, add, commit becomes a rhythm.

Good commit habits

• Commit often. Small, frequent commits are easier to understand and undo than one giant one.
• One logical change per commit. Don't mix a bug fix and a new feature in the same snapshot.
• Write messages for your future self. "Stuff" tells you nothing; "Fix crash when name is empty" tells you everything.

Try it yourself

Practise the full loop on a small project:

• Create a folder for a tiny website or a Python script and run git init inside it.
• Add one file, then stage and commit it with a clear message.
• Edit the file (change a line), run git status to see the change reported, then add and commit again with a new message.
• Run git log --oneline and admire your growing history.
• (Bonus) Make a change you don't like, then experiment with git diff to see exactly what's different before deciding whether to commit it.

Once you're comfortable with this local workflow, the natural next step is sharing a repo online with GitHub. Connecting Git to a project also pairs well with everything you've built so far, like your first web page or first Python program — put them in a repo and never lose your work again.