Git and GitHub, explained

What you'll learn: what version control is, why it beats saving copies of files, and how Git, GitHub and the command line fit together.

Meet Sam and the bakery website

Sam is a freelance web designer. Her current job is a small website for Rosa's Bakery: a home page, a menu page, a page with opening hours and a contact form. It is only a handful of files, but she has already run into the problem every designer knows. Her folder looks like this:

• index.html
• index-old.html
• index-rosa-feedback.html
• index-FINAL.html
• index-FINAL-2.html

Which one is live? What changed between the second and third? When Rosa says "I preferred the header from two weeks ago", which file has it? Sam isn't sure. And soon her friend Leo, a developer, is going to help with the contact form, which means two people editing the same files.

This course follows Sam from that messy folder to a calm, shared project on GitHub.

What version control does

Version control is a system that records the changes to a set of files over time, so you can see what changed, when, why and by whom, and go back to any earlier version. Instead of you making copies with ever-longer names, the system keeps the history for you, and your folder holds just one current version of each file.

Think of save points in a video game. Before a tricky level, you save. If things go badly, you reload the save point and try again, without replaying the whole game. Version control gives your project save points, except that each one also carries a note saying what you did, and you can keep as many as you like.

Those save points are called commits. A commit is a snapshot of the whole project at a moment you choose, plus a short message, your name, and the date. Commits form a timeline you can read, compare and return to.

Version control also helps when several people work on the same files. It can combine their changes, and when two people change the same lines it flags the clash instead of silently keeping one and losing the other.

Git and GitHub are different things

People often say "Git" and "GitHub" as if they were the same. They are not.

Git does the actual version control: it records commits, manages history and combines changes. GitHub stores a copy of a Git project online so others can get it, and adds collaboration tools such as pull requests, code review and issue tracking. You can use Git without GitHub for years; you cannot meaningfully use GitHub without Git. Git is by far the most widely used version control system today, which is why this course is about it.

Sam will spend the first two-thirds of this course using Git alone on her laptop. GitHub comes in when Leo joins.

Git is distributed

Older systems kept the history on one central server, and you needed to be connected to save a version. Git is distributed: every copy of a project, on every computer, holds the full history. Sam can commit on a train with no signal, look back through months of history, and only connect to share her work. If GitHub disappeared tomorrow, every copy on every laptop would still hold the whole project.

Installing and introducing yourself

Git is a command-line program, and this course uses the commands directly, because they work the same everywhere and they are what every guide and error message refers to. Graphical tools such as GitHub Desktop, and the Git features built into editors like VS Code, run the same commands behind their buttons, so what you learn here carries straight over.

To get set up:

1. Install Git. On Windows, use the official Git for Windows installer, which includes a terminal called Git Bash. On a Mac, Git is offered when you first run git in Terminal (it comes with Apple's command line tools), or you can install it with Homebrew. On Linux, use your package manager, for example sudo apt install git on Ubuntu.
2. Check it worked by opening a terminal and running git --version. Any recent version is fine for this course.
3. Tell Git who you are, since every commit records it. Sam runs these two commands, once per computer:

git config --global user.name "Sam Rivera"

git config --global user.email "sam@example.com"

The --global part means the setting applies to every project on this computer. Use the email you plan to use on GitHub, so your commits are linked to your account there.

One more setting is worth making now. Every project has a default branch (you will meet branches properly later). For years Git called it master; GitHub, GitLab and Bitbucket now name it main for new repositories, and many guides follow them. Depending on your Git version and settings, a new project may use either name. To make Git use main, which this course does, run:

git config --global init.defaultBranch main

If you join a project that uses master, nothing in this course changes except the name.

Recap

• Version control records a project's history as a series of snapshots called commits, each with a message, an author and a date, like save points in a video game.
• It replaces copies with names like index-FINAL-2.html, and helps several people change the same files safely.
• Git is the version control program on your computer; GitHub is an online service that hosts Git projects and adds collaboration tools.
• Git is distributed: every copy holds the full history and works offline.
• Set your name and email with git config --global before your first commit; the default branch may be called main or master.

What you'll learn: how to turn a folder into a Git repository and record your work in commits, using the staging area to choose exactly what each commit contains.

Turning the folder into a repository

Sam starts by tidying up. She keeps the newest version of each page, deletes the index-FINAL-2.html style copies, and is left with a clean folder called rosas-bakery holding index.html, menu.html, styles.css and an images folder.

In a terminal, she moves into that folder and runs:

git init

Git replies that it has initialised an empty repository. A repository (or repo) is a project that Git is tracking. Nothing visible has changed, but Git has created a hidden folder called .git inside rosas-bakery. That folder is where the whole history will live. Don't edit or delete it: deleting .git deletes the history, though your current files stay.

Asking Git what is going on

The command Sam will use more than any other is:

git status

Right now it says she is on branch main, there are no commits yet, and it lists her files as untracked: Git can see them but has not been told to look after them. Run git status whenever you are unsure. It is always safe, it changes nothing, and it usually suggests the next command.

The three places your work lives

Here is the idea that confuses most beginners, so it is worth slowing down. Git thinks of your work as being in one of three places:

Why the middle step? Think about packing a parcel. You lay things out on the table (your working directory), then choose which ones go into the box (the staging area), and only then seal it and write the label (the commit). Some things on the table may not be ready to send, so they stay out of the box for now. The staging area lets you make each commit about one thing, even if you have been working on several things at once.

Sam's first commit

Sam stages everything for her first commit. The dot means "everything in this folder and below":

git add .

git status now lists the files under "Changes to be committed". They are in the box. Then she seals it:

git commit -m "Add first version of the bakery site"

The -m gives the commit message in quotes. If you leave it out, Git opens a text editor for you to write the message; save and close the editor to finish. Git replies with a short summary, including the first characters of the commit's id, a string of letters and numbers like 3f2a9c1. Every commit gets a unique id like this, called its hash.

git status now says "nothing to commit, working tree clean". That means the files in the folder match the last commit exactly. It is the state you want to be in at the end of a piece of work.

Choosing what goes in

The next morning, Rosa emails two requests: the Saturday opening hours are wrong on the home page, and could the headings be a darker brown? Sam fixes the hours in index.html, then starts experimenting with colours in styles.css. The hours fix is done; the colours are not.

git status shows both files as modified. If she committed everything, a finished fix and a half-finished experiment would be bundled together in one snapshot. Instead she stages just the finished file:

git add index.html

git commit -m "Fix Saturday opening hours on home page"

The colour changes in styles.css are untouched. They are still in her working directory, waiting, and git status still lists them as modified. Later, when the colours are right, she will stage and commit them separately.

One detail catches people out. git add copies a file into the staging area as it is at that moment. If Sam stages index.html and then edits it again before committing, the commit gets the staged version, and the newer edit shows up as a separate, unstaged change. When in doubt, run git status just before git commit.

Seeing changes before you stage them

Before staging, it helps to see exactly what changed. git diff shows the lines that differ between your working directory and the staging area:

git diff styles.css

Removed lines start with a minus sign and added lines with a plus sign. Sam sees her colour change from #6b4a2b to #4a2f18 and the stray test rule she meant to delete. Reading the diff before every commit is a habit that catches a lot of accidents. The next lesson covers diffs and history in more detail.

A few useful variations

1. git add images/ stages everything in one folder.
2. git add -p walks through the changes in a file piece by piece and asks which to stage, handy when one file contains two separate edits.
3. git commit -a -m "message" stages every change to files Git already tracks and commits in one step. It is convenient, but it skips the choosing, so use it only when you are sure everything belongs together. It does not include brand-new files.

New files must always be added once with git add before Git will track them. After that, Git notices whenever they change.

Recap

• git init turns a folder into a repository; the history lives in the hidden .git folder.
• git status is always safe and tells you where everything stands.
• Work moves from the working directory, to the staging area with git add, to the repository with git commit, like packing a parcel before sealing it.
• Stage only what belongs together, so each commit is about one thing.
• git add stages a file as it is at that moment; later edits need staging again.
• git diff shows what changed before you stage it.