What is GitHub flow? The workflow explained for PMs

Alex Tutor

Friday afternoon, right after the product meeting. Which question did you hear most today?

You

"Is it live yet?" Three times. Once about the checkout fix, twice about Emma's autumn sale banner.

Alex Tutor

Then let's put the whole path of a change on one picture. The team has a name for it: GitHub flow. You've already seen every step, just never all at once.

Alex Tutor

main over the last two weeksThree changes, three short branches. Each started from main, went through a pull request and came back as one squash commit. Every merge into main was deployed within minutes.

e7c3b19Add summer promo banner
e19c3b7Rewrite delivery page copy
f02a6d4Update FAQ answers
3a9d1c4Reproduce bug in a test
8be2f70Add cat treats bundle
5c1d7e2Set freeDeliveryFrom to 1000
a8f40b9Update delivery page text
d36b9c5Update cart hint textfeature/free-delivery-1000
b7e4a05Re-enable button after cart edits
6f2c8a1Raise free-delivery threshold to 1000 UAH (#133)
c90d4e7Merge branch 'main' into content/delivery-copycontent/delivery-copy
a7d93e4Rewrite delivery page copy (#132)
c2d7f90Update checkout hint copy
f7a2b61Restore checkout button colour
9e3b5d2Merge branch 'main' into fix/checkout-buttonfix/checkout-button
d51c7e8Fix checkout button after cart edits (#134)main

You

Emma's copy, Daniel's threshold, Daniel's checkout fix. None of those branches lived longer than about a week.

Daniel

That's the point. main is always a version we could put on the site right now. Anything unfinished waits on its own branch, or, as you'll see today, behind a switch.

Alex Tutor

So the loop is short: a small branch from main, a pull request, a merge, a deploy. Then the next change starts again from fresh main.

Alex Tutor

Question 1

Put the steps of GitHub flow at CatChow in order, from the idea to customers seeing the change.

Tap an item, then tap where it should go. You can also drag or use the arrows.

You

On Wednesday Daniel said "give it five minutes". What happens in those five minutes?

Daniel

A GitHub Actions workflow takes the new main, builds the site and puts it on our servers. That's the deploy. It's a job like build and test, except it runs on main after a merge.

Alex Tutor

#134 on Wednesday morning

Fix checkout button after cart edits#134
Merged into main at 9:40 as d51c7e8
deploy (production)
Ran on d51c7e8 in main, finished at 9:44

So "merged" and "deployed" are two events. At CatChow they're minutes apart, and the second follows the first on its own. In other teams they can be weeks apart.

You can check it without asking anyone. As of 2026 the repository page has a Deployments section in the right column. Click production to see which commit is live and since when.

You

And if the deploy fails?

Daniel

Then main has the change and the site doesn't. We get an alert and either fix it right away or revert. A broken main blocks everyone's next deploy, so it jumps the queue.

You

So before I tell support that something is live, I check production under Deployments.

Alex Tutor

That, and one look at the live site itself. The deploy tells you the code arrived; your own eyes tell you it works.

Alex Tutor

Question 2

At CatChow, the moment #134 shows Merged, every customer already sees the fix on the site.

TrueFalse

You

Why keep branches so short, though? Wouldn't it be easier to build the whole feature and merge it once?

Alex Tutor

Remember feature/loyalty-points? Twelve commits ahead, 86 behind, untouched for five months. That's what "merge it once, at the end" tends to turn into.

Daniel

Every day a branch lives, main moves on without it. The further behind, the more chances of conflicts, or of a surprise like my checkout button in March.

Alex Tutor

Small pull requests are also reviewed faster and better. Forty changed lines take ten careful minutes. Two thousand wait for someone's free afternoon, and then get skimmed.

Daniel

And they're easier to undo. If one small change breaks something, Revert removes exactly that. Revert a huge one, and ten good changes leave with the bad one.

You

So small isn't about tidiness. It's less risk per merge.

Alex Tutor

Exactly. A rule of thumb many teams use: a branch that lives a few days, and a pull request someone can review in one sitting.

Alex Tutor

Question 3

Why does CatChow prefer small pull requests on short-lived branches? Select all that apply.

Choose all that applyGitHub rejects pull requests longer than 500 linesThe branch falls less far behind main, so conflicts are rarerReviewers can read the whole change carefully in one sittingSmall pull requests don't need approvalIf something breaks, a revert undoes one small change

You

Can I spot a branch like that before it becomes a problem?

Alex Tutor

On the branches page, yes. Look at two things: when the branch was last updated, and how far behind main it is. Old and far behind is the warning sign.

Daniel

And at its pull request. If Files changed says 60 files for "a small tweak", ask why. A question early is cheaper than a painful review later.

Alex Tutor

On a graph it's the same story: a long lane that started high up, while main kept collecting commits next to it.

Alex Tutor

Question 4

Both branches are about to get a pull request. Which statement fits GitHub flow best?

Two branches waiting to be merged

a1
w1
a2
w2
a3
w3
a4
w4
a5
w5feature/wishlist
a6main
x1fix/footer-links

Choose one answerfix/footer-links is riskier: it has fewer commits, so it was tested lessBoth are equally risky: the risk depends only on who reviews themfeature/wishlist is riskier: it is 5 commits behind main and holds five commits of work in one pull requestNeither can be merged until main stops changing

You

Now Emma's banner. The sale starts on Monday. If she merges today, the banner goes live today and announces a sale that hasn't started.

Alex Tutor

And if she waits until Monday morning, the review, the merge and the deploy all happen in a rush while customers are already arriving.

Daniel

That's what a feature flag is for: a switch around a piece of the site. The code is in main and deployed, but the banner shows only while the flag is on.

Alex Tutor

At CatChow the switches live in a flag settings panel, outside the repository. Turning one on needs no pull request and no deploy.

Daniel

I added the check to Emma's branch: flag autumn-sale-banner, off by default. Emma marked #136 ready for review, I approved it, and she merged it an hour ago.

Alex Tutor

Question 5

On Saturday a customer opens the CatChow home page. What do they see?

#136 on Saturday

Add autumn sale banner#136
Merged on Friday · flag autumn-sale-banner: off
deploy (production)
Finished on Friday

Choose one answerThe autumn sale banner, because #136 is mergedAn error, because the banner code is deployed but switched offThe banner, but only after reloading the pageThe home page without the banner: the code is live, the flag is off

You

So the banner is on the site, but nobody can see it.

Alex Tutor

Merged, deployed, hidden. On Monday at 8:00 Emma switches the flag on, and customers see the banner within seconds. If something looks wrong, she switches it off, again with no deploy.

Daniel

Flags also let us merge unfinished work. The half-built part stays switched off, so main stays deployable while a feature grows in small pull requests.

Alex Tutor

One catch: every flag is an extra "if" in the code. Once a feature is on for good, someone removes the flag, or the code fills up with forgotten switches.

You

Someone from marketing will ask me whether the banner is live the moment they see #136 merged.

Alex Tutor

Then answer so it can't be misread. "Yes" is wrong, and "no" is only half the truth.

Daniel

And please mention the time. People plan newsletters around it.

Alex Tutor

Two or three sentences, as a chat reply.

Alex Tutor

Question 6Short answer · AI-checked task

A marketing colleague writes: "#136 is merged, so the sale banner is live? Can I send the newsletter tonight?" The sale starts on Monday; the flag autumn-sale-banner is off and Emma switches it on at 8:00 on Monday. Write your 2–3 sentence reply.

Write your answer and get a score with feedback from our AI reviewer.

Log in to get AI feedback

You

The CEO asked about loyalty points again today. Can Daniel just merge the old branch now?

Daniel

Not a chance. It's 86 behind, and half of what it touches has changed since. I'll rebuild it on fresh main in small pull requests, all behind one flag: loyalty-points.

Alex Tutor

Each piece is merged and deployed on its own, invisible to customers. The feature is "launched" only on the day the flag goes on for them.

Daniel

Sofia, could you draft how we slice it? You know what customers need first. I'll tell you what's technically possible.

You

A slice plan, then: the pieces, their order, what stays hidden, and when we call it launched.

Alex Tutor

Question 7Case · AI-checked task

Draft the slice plan for loyalty points in GitHub flow.

Loyalty points: customers earn 1 point for every 10 UAH of a paid order, see their balance in their account, and can spend points as a discount at checkout. Emma writes the page that explains the programme. The old branch feature/loyalty-points is abandoned. The CEO wants the programme "launched before Black Friday", about six weeks away.

Daniel will rebuild it on fresh main, behind the flag loyalty-points. CatChow deploys every merge into main within minutes, and the flag can be switched on for staff only or for everyone.

Write a plan of 4–6 pull requests: what each one contains and in what order, what customers see after each merge, how the team tests before launch, what "launched" means and how to roll back, and what you will watch to report progress.

Write your answer and get a score with feedback from our AI reviewer.

Log in to get AI feedback

Alex Tutor

Wednesday next week. The team took your plan and added a loyalty label. Filter the pull requests by it, and the feature's progress reads itself.

Alex Tutor

Pull requests with the label loyalty

Add loyalty points behind a flag#155
by Daniel · merged on Tuesday · flag loyalty-points: off
Earn points on paid orders#156
by Daniel · Review required · checks passed
Write loyalty programme page#157
by Emma · Draft

You

One piece is in main and on the site, but hidden. One is waiting for a reviewer. Emma's page is still a draft.

Daniel

And that's why nobody should announce anything yet, even though loyalty code has been live since Tuesday.

Alex Tutor

The pull request list shows how far the building has got. The flag shows what customers see. To answer "where is the feature?", a PM reads both.

You

And a merged pull request with the flag off means "done and hidden", not "launched".

Alex Tutor

Question 8

Match each thing you can see about loyalty points with what it tells you.

Tap an answer, then tap the row it belongs to. You can also drag.

#155 Merged, flag loyalty-points off
#156 open, "Review required", checks passed
#157 Draft
Flag loyalty-points switched on for everyone

Answers left to place

That's GitHub flow: main always deployable, small branches, a pull request for everything, deploy on merge, and flags for anything that isn't ready for customers.

You

Support asked me today which version the checkout fix went out in. We don't have versions, do we?

Daniel

Not yet. Some teams live by version numbers and release branches. Next lesson you'll see one, and why we don't work like that.

Alex Tutor

That’s the lesson. You answered every task — nicely done.

Next lesson: Git flow: develop, release and hotfix branches