The Five Steps That Make GitHub Click

So picture a developer, Friday afternoon, deadline in an hour, and she just overwrote the one file the whole release depends on. How did she get there?

She had no version history. No repository. That's exactly what a repository prevents — it holds the project files and their full revision history.

So it's not just a folder of code?

No. It's a folder plus a permanent record of every change, plus a place to discuss and manage the work. Lose a file, the history still has it.

Mm. Okay, so the repo is step one. What comes next?

A branch. Think of it like a copy of the main line where she could have worked safely.

Why not just edit the main line directly? Faster, right?

Faster until Friday afternoon happens. Changes on a branch don't enter the default branch until they're merged. So her experiments stay contained.

So the main line never even sees her edits until someone decides?

Exactly. That's the whole point of GitHub's flow — you create the branch before making changes.

And while she's on the branch, she saves her work how?

With commits. A commit records the changes on the branch, plus a message describing what's in it.

Any commit message works?

A descriptive one. GitHub recommends small, meaningful commits — the messages become a running history future contributors can read.

Like a lab notebook, almost.

That's a good analogy. And after committing, she pushes the branch to GitHub so she can propose the changes for review.

Wait — propose? She can't just put them in?

the pull request. It proposes changes from one branch into another, and gives collaborators a place to review and discuss before anything merges.

Give me a concrete example of what that looks like.

Suppose she fixed a broken login button. She opens a pull request: the base branch is main, the branch with her fix is the compare branch. Title, description, what changed and why.

And if the fix isn't finished yet?

She can open it as a draft — signals it's not ready for review. And, this is the neat part, any commits she pushes later to that same branch get added to the pull request automatically.

Automatically?

Automatically. Reviewers comment, she responds with more commits, all in one place.

So what actually blocks a bad change from going in?

A repository can require an approving review before merging. It can also require status checks to pass — automated tests, for example.

So merging isn't just clicking a button—

Not yet. Once requirements are met, someone with write permission merges it. And a draft pull request can't be merged at all.

Okay, the merge itself. Is there more than one way to do it?

Three ways, actually. Create a merge commit, squash the commits into one, or rebase them onto the base branch.

And these differ how, in plain words?

The default merge method uses what's called the --no-ff option — it creates a merge commit that preserves the branch's commit history.

Whereas squash and merge —

Combines everything into one single commit. The individual commits don't appear separately on the base branch. Rebase and merge does the opposite — adds them individually, no merge commit.

So the team can enforce which method contributors use?

A repository can configure which methods are allowed, or enforce one. Some teams are very opinionated about this.

I believe it. And after the merge, is the branch just... left there?

Deleting it is optional — it keeps the branch list tidy. GitHub can even auto-delete it after merging if that option's enabled.

So our Friday developer — the whole loop would've saved her?

The whole loop. Branch, commit, pull request, address feedback, merge. It's iterative — you run it again and again.

Five steps, and none of them touch the main line until everyone agrees. No wonder it's the standard.

And now she'd have history, review, and a merge button instead of one very bad Friday.