Just Web Academy · Module 02

GitHub, in plain words

What your developers are doing all day — and how to work with them without pretending you understand.

Audience: Non-developers
Length: 25 minutes
Code you write: None

The four buttons you will actually press

Fetch origin

Goes and looks at the shared copy to see if anything is new. Changes nothing.

Pull

Brings in the newest shared work, down onto your computer.

Push

Sends out the work you have saved, up to the shared copy.

Branch

Chooses which version of the project you are working on.

Git is the tool. GitHub is the website where a team uses it together. That is the whole difference, and you can forget it now.

Slide 01 · the story

Everyone has a folder called final_v2_FINAL. Developers do not.

Nobody plans to lose a day of work. They just save over it.

You know the folder. Five copies of the same file, the version in the filename, and no way to tell which one the client actually approved. Somebody opens the wrong one and a week of edits quietly disappears.

Developers hit this problem long before we did, and they solved it properly. Every change they make is saved as its own small, dated, signed entry — and nothing is ever written over.

Four questions, asked on a Monday morning

What changed?
Open both and compare by eye Listed line by line
Who changed it?
The date, never the person Name on every change
Why was it changed?
Nobody wrote it down A note on each one
Can we undo it?
Only if someone kept a copy Any change, any day

Takeaway

GitHub is not a place to store code. It is a record of every change ever made, and a button to undo any of them.

Slide 02 · the three words

Three words cover almost everything you will hear.

Repository

The project folder — the whole website, plus every version of it that has ever existed. Everyone says repo.

Commit

One saved change, with a short note saying why: Fixed the broken contact form.

History

Every commit in order, oldest to newest. This is the time machine, and you can scroll it.

The commit note is the part you can read. You can follow a whole project without ever looking at a line of code.

You already use a tool that works this way.
In Google Docs	In GitHub
The document	Repository
Version history	Commits
Suggesting mode	Pull request
Comments in the margin	Review comments
Accepting a suggestion	Merge

Takeaway

If you can read a list of dated notes, you can read a project history. That is genuinely most of it.

Slide 03 · one change, start to finish

Nothing reaches the live site without somebody approving it first.

What happens to a single fix

Branch

A safe copy of the project. All the work happens here, so the live site is never touched while it is in progress.
Commit

The change gets saved, with its note. There may be one commit or twenty.
Pull request

Plain English: please look at this before it goes in. This is the page where the whole team discusses the change.
Review

Somebody reads it, leaves comments, and either approves it or asks for changes.
Merge

Approved. The change joins the real project and stops being a side copy.

The pull request is where you come in

There is usually a preview link. Open it and look at the actual page.
Comment on anything wrong — wording, spacing, a wrong phone number.
Approve only once you have looked. Approving is a signature.
If it turns out wrong later, the whole thing can be reversed in one click.

Merged does not mean live. Merging puts the change into the project. Putting it on the real website is a separate step called a deploy, and it may happen minutes or days later. Always ask which one has happened.

Takeaway

The pull request is the safety net, and it is your chance to catch things while they are still cheap to fix.

Slide 04 · working in parallel

Two people, one project, the same afternoon — and nothing gets overwritten.

Two weeks on one project. Each colour is one person.

Same starting point

Each takes their own branch off main. Two copies, neither of them the real project yet.

At the same time

John cannot break what Karen is doing, because neither is touching main. No waiting, no taking turns.

Merged when approved

Each merges on its own schedule. Both changed the same line? GitHub asks a person to choose — that is a conflict.

Nothing is ever lost

Once pushed, it is off your laptop and backed up
Any earlier version can be brought back
Every change shows what moved, and who moved it

Takeaway

Branches are why nobody has to wait their turn, and the history is why nobody can lose work. Between them, that is most of what GitHub buys a team.

Slide 05 · where the buttons send things

There are only two boxes. Every button just moves things between them.

The box inside your house

Your project folder, on your own computer

Only you can open it
Nobody else can see what is in it
A safe place to make a mess

Push

Takes what is in your box and puts a copy in the shared box.

Pull

Takes what is in the shared box and puts a copy in your box.

Fetch origin

Walks out and looks in the shared box. Tells you what is new. Carries nothing back.

The box outside, on the street

GitHub — the shared copy

Everyone on the team can reach it
This is the copy that counts
Your computer calls it origin

Branch is not a direction. Both boxes can hold several versions of the project side by side. A branch just picks which one you have open. Switching branch changes what you see in your folder; it sends and receives nothing.

Pull and pull request are different things. A pull brings work into your box. A pull request asks the team to review work you have already pushed out. Same word, unrelated jobs.

Takeaway

Push sends, pull receives, fetch only looks. Until you push, your work exists on your laptop and nowhere else — so it is not backed up and nobody can help you with it.

Reference · keep this open

Every word, in one place.

Repository (repo): The project folder, plus its whole history.
Commit: One saved change.
Commit message: The short note saying why it changed.
History: Every commit, in order.
Branch: Which version of the project you have open.
Main: The branch that counts. The real one.
Origin: The name your computer uses for the shared box on GitHub.
Push: Send your saved work out to the shared box.
Pull: Bring the newest shared work into your box.
Fetch origin: Look in the shared box. Move nothing.
Clone: Take your first copy of a project onto your computer.
Pull request (PR): Please review this before it goes in.
Review: Reading a change and approving or objecting.
Merge: Approved. The change joins the real project.
Conflict: Two people changed the same line. A human has to choose.
Issue: A written-down bug or request, with a discussion under it.
Deploy: Putting the project onto the live website. Separate from merge.
Revert: Undo a change that already went in.

End of module

Two boxes, four buttons, one review step. If you remember that push sends and pull receives, you already understand most of what you will see on screen.