An Introduction to Git

If you’ve ever ended up with a folder full of report-final.docx, report-final-v2.docx and report-final-v2-ACTUAL.docx, you already understand the problem Git solves. It’s just done for code (and text files generally), properly, at scale, with multiple people involved.

Git is a distributed version control system. Every change you make to your files gets tracked, so you can see what changed, roll back to an earlier point, and work on several things at once without them getting tangled up. “Distributed” means your local copy has the entire project history in it, not just the latest files, so most of what you do with Git happens without needing an internet connection at all.

One thing worth clearing up early: Git and GitHub aren’t the same thing. Git is the tool that runs on your machine. GitHub is just one of several places you can host a copy of your Git repository online (GitLab and Azure DevOps are others). You can use Git perfectly well without ever touching GitHub.

The basic idea

Your work moves through four places:

• Working directory – the files on your disk, exactly as you’re editing them
• Staging area – the changes you’ve picked out to go into your next save point
• Local repository – your committed history, stored on your own machine
• Remote – the shared copy, usually on GitHub, that other people (or your other machines) can see

The everyday flow is: edit a file, stage it, commit it, push it. That’s genuinely most of what you’ll do.

A commit is a snapshot of the whole project at that moment, with a message explaining what changed and why. A branch is a lightweight, disposable label pointing at a commit. It costs nothing to create, which is why you’re encouraged to make one for almost anything you’re working on, then merge it back in once it’s done.

Getting set up

If this is a new machine, tell Git who you are once:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main

Then either clone something that already exists:

git clone https://github.com/user/repo.git

Or start tracking a folder you already have:

git init
git remote add origin https://github.com/user/repo.git

Commands you’ll actually use

You don’t need to memorise Git’s entire command set. This is genuinely most of it:

git status              # what's changed, what's staged, what branch you're on
git add .                # stage everything you've changed
git commit -m "message"  # save a snapshot of what's staged
git push                 # send your commits to GitHub
git pull                 # bring down anyone else's commits
git switch -c new-thing  # create a branch and move onto it
git switch main          # move back to an existing branch
git log --oneline        # a compact history of commits

If you only remember six commands, make it status, add, commit, push, pull and switch.

A simple workflow to follow

This is the loop I’d tell anyone starting out to stick to:

git switch main
git pull                                 # start from the latest version

git switch -c fix-header-typo            # branch for the thing you're doing

# ...make your changes...

git status                               # sanity check what you've touched
git add .
git commit -m "Fix typo in page header"

git push -u origin fix-header-typo       # send the branch up

# open a pull request on GitHub, get eyes on it, merge it

git switch main
git pull
git branch -d fix-header-typo            # tidy up

If you’re working solo on something small, you can skip the branching altogether: edit, git add ., git commit -m "...", git push. Nobody’s going to tell you off.

A few things worth knowing early

• Write commit messages that explain why, not what. “Fix login timeout causing false logouts” is useful in six months. “Update file” is not.
• Small, frequent commits beat one giant one. They’re easier to review, and much easier to undo if something’s wrong.
• Pull before you start work, every time. Most merge conflicts happen because you started from a stale copy.
• Never commit secrets. Once a password or API key is in your history, it’s there permanently, even after you delete the line. Use a .gitignore and rotate anything that leaks.
• git reflog is your safety net. It remembers where you’ve been for the last few months, so “I think I’ve broken everything” is usually recoverable.
• Nothing is really lost until you push. Mistakes on your own machine, before they’ve gone anywhere, are almost always fixable.

Get comfortable with that loop and those commands, and you’ve got the 90% of Git that covers almost everything you’ll need day to day.