Most people meet version control the hard way: a folder full of report-final.docx, report-final-v2.docx and report-final-REALLY-final-John-edits.docx, and nobody sure which one is the real one. Git is the grown-up answer to that folder, and GitHub is where most of the world keeps its Git projects. This website reaches you through it: every change to these pages is a branch, a pull request and a merge on GitHub before it goes live. Here is how it all works, one picture at a time.
Git and GitHub are two different things
The names cause most of the confusion, so start here.
- Git is free, open-source software that runs on your own computer. Point it at a folder and it records every saved version of every file in it, who changed what, when, and why. Linus Torvalds wrote it in April 2005 to manage the Linux kernel, after the tool the kernel developers had been using was withdrawn. (He has joked that he names his projects after himself; “git” is British slang for an unpleasant person.)
- GitHub is a website, launched in 2008 and bought by Microsoft in 2018, that stores copies of Git projects online and adds the tools people need to work on them together: pull requests, code review, issue tracking, automation and web hosting.
Git is distributed. That means there is no single master copy that everyone has to log in to: every computer that works on a project holds the entire history. GitHub is simply the copy everyone agrees to meet at.
A project tracked by Git is called a repository, or repo. On your computer it looks like a normal folder. The only difference is a hidden .git folder inside it, where Git keeps the history.
The commit: a saved snapshot with a note attached
The basic unit of Git is the commit. When you make a commit you are telling Git, “remember the project exactly as it is right now”. Each commit records:
- a snapshot of every file in the project at that moment (Git is clever about storage: files that didn’t change aren’t stored twice);
- who made it, and when;
- a short message saying why, such as “Fix a typo on the pricing page”;
- and the ID of the commit that came before it, its parent.
That last item is what turns a pile of snapshots into a history. Each commit points back to its parent, so the commits form a chain all the way back to the first one.
Because every version is kept, you can open any old commit and see the project exactly as it was, compare two versions line by line, or undo a single change made three months ago without disturbing anything since.
Where the strange IDs come from
Commits aren’t numbered 1, 2, 3. Each one is named by a hash: a fingerprint calculated from everything inside the commit, written as 40 letters and digits such as 3f7a9c1e0b84d2…. People usually quote just the first seven characters. By default Git calculates it with an algorithm called SHA-1; Git 3.0 is planned to switch new repositories to the stronger SHA-256. (We explain how hashes work in how a computer knows a file isn’t broken.)
This has a useful side effect: a Git history is tamper-evident. If anyone altered an old commit, its ID and the ID of every commit after it would change, and every other copy of the repository would immediately disagree. It also means two copies of a project can work out exactly which commits they share just by comparing IDs, which is how push and pull know what to send.
Three places a change lives on your computer
Git doesn’t save every keystroke. You choose when to commit, and you choose what goes into each commit. To make that possible, a change passes through three places on your computer before it reaches GitHub.
git add picks which changes belong in the next commit, git commit saves them to your local history, and git push sends your new commits to GitHub. git pull brings other people’s commits back down.- The working folder. The files you open and edit with your normal programs. Git leaves them alone until you ask it to switch branch or pull.
- The staging area. A holding pen for the next commit. If you fixed a typo and also started a half-finished new section, you can stage just the typo fix and commit it on its own, with its own message.
- The local repository. Your saved commits, inside the hidden
.gitfolder. Committing is instant and works with no internet connection at all.
Only push sends your work to GitHub. Until you push, your commits exist only on your computer, which is worth remembering before a laptop goes in for repair.
Branches: a safe place to try something
A branch is a separate line of commits that splits off from the main history. You can make as many commits on it as you like, and none of them touch main until you decide they should. Under the hood a branch is nothing more than another label pointing at a commit, like the main label in the chain above, so branches are instant and cost almost nothing.
The usual habit is one branch per job: a new page, a bug fix, an experiment. If the experiment fails, you delete the branch and main never knew it existed. If it works, you merge it.
Merging is usually automatic. Git compares the changes line by line, so if one person edited the top of a file and another edited the bottom, both edits are simply combined. Only when two branches changed the same lines does Git stop and report a merge conflict. It marks both versions in the file and waits for a person to choose. That’s a feature: Git never silently picks a winner.
The main branch was traditionally called master, and plenty of older projects, including our own website, still use that name. GitHub has named it main in new repositories since 2020, and Git 3.0 is planned to do the same. It works exactly the same either way.
Pull requests: how a team agrees on a change
Git itself has no idea who is allowed to merge what. That social layer is GitHub’s biggest contribution, and its centrepiece is the pull request (GitLab calls the same thing a merge request). A pull request is a page on GitHub that says: “here is my branch; please review it and merge it into main.”
On the pull request page, reviewers see exactly which lines changed, with old and new side by side. They can comment on a specific line, ask for changes or approve. Automatic checks can run at the same stage: tests, spelling, a build of the website. GitHub shows a green tick or a red cross next to each one. The project owner can make those rules compulsory. Branch protection can require an approval and passing checks before anyone can merge into main, and, if “Do not allow bypassing” is ticked, the owner too. (On a private repository, branch protection needs a paid plan, GitHub Pro or Team; on the free plan it covers public repositories only.)
This is the loop this page went through. It was written on its own branch, opened as a pull request, reviewed, and only went live once it had been merged and deployed.
Forks and clones: copying a project
Two words for copying come up constantly, and they mean different things.
- Clone means downloading a repository from GitHub to your computer, with its full history, so you can work on it. If you have permission to the original, you clone it, branch, push and open pull requests directly.
- Fork means making your own copy of someone else’s repository on GitHub, under your account. It’s how strangers contribute to open-source projects they have no permission to change.
Forking is why open source scales. Anyone can propose a fix to a project used by millions without the maintainers handing out keys. They review the pull request and accept it or not. Our own audio player, Ironbark, is public on GitHub for exactly this reason: anyone can read the code, fork it, and suggest a change.
What GitHub adds on top of Git
Pull requests are the headline feature, but most teams end up using several of the others too:
| Feature | What it does |
|---|---|
| Issues | A to-do list and bug tracker attached to the project. Issues can be assigned, labelled and closed automatically by the pull request that fixes them. |
| Actions | Automation that runs on GitHub’s computers when something happens, such as running the tests on every pull request or publishing a new version when a release is tagged. |
| Pages | Free hosting for a static website straight from a repository (from public repositories on the free plan). |
| Releases | Packaged, downloadable versions of a project with release notes, such as an installer for version 1.2. |
| Security alerts | Warnings when a project depends on a library with a known vulnerability (free everywhere), and scanning that catches many accidentally committed passwords and keys (automatic on public repositories; on private ones it’s a paid add-on). |
| Copilot | GitHub’s AI assistant, which suggests code in your editor and can draft pull requests and reviews. It is a separate product with its own plans. |
The handful of commands that do almost everything
You don’t need to memorise Git. GitHub Desktop and editors like Visual Studio Code put buttons on all of this, and small edits can be made straight in the browser. But if you see these in a guide, here is what they mean:
| Command | In plain English |
|---|---|
git clone <address> | Download a repository and its full history. |
git status | What have I changed, and what’s staged? |
git switch -c new-page | Make a new branch called new-page and move onto it. |
git add about.html | Stage this file’s changes for the next commit. |
git commit -m "Add team photo" | Save the staged changes as a commit with that message. |
git push | Send my new commits to GitHub. |
git pull | Fetch everyone else’s new commits and merge them into mine. |
git log | Show the history, newest first. |
git diff | Show exactly which lines changed. |
What Git is not good at
Git was built for text: code, web pages, configuration, documentation. It can tell you that line 42 of a page changed. It works less well with:
- Big binary files. Videos, Photoshop files and disk images can’t be compared line by line, and every version is stored in full, so the repository balloons. GitHub refuses individual files over 100 MB. Git LFS (Large File Storage) exists for this, but often a different tool is the right answer.
- Word and Excel files. Git will happily keep every version, but it can’t show what changed inside them or merge two people’s edits. For office documents, the version history built into Microsoft 365 or Google Drive does that job better.
- Secrets. Passwords, API keys and customer data must never be committed. Deleting a secret in the next commit doesn’t remove it: it’s still in the history, on every clone. If it happens, treat the key as leaked and replace it. Then keep secrets in a separate file that Git is told to ignore, which is what
.gitignoreis for.
What this means for your business
If anyone in your business writes code, builds websites or keeps technical documentation, they should be using Git. GitHub’s free plan covers unlimited private repositories, which is enough to start. Three settings matter more than the rest: keep repositories private unless you mean to publish them, turn on branch protection so nothing reaches main without a review (for private repositories that needs GitHub Pro or Team, a few dollars a user a month), and make sure no passwords or keys are in the history. Remember too that GitHub is a second copy, not a full backup. Someone with access can still delete a repository, so anything important deserves one more copy somewhere else.