GitHub flow: small branches, fast merges

GitHub flow is a short loop around one rule: main is always a version you could put on the site right now. Every change makes the same trip:

1. Create a short-lived branch from fresh main: git switch -c fix/footer-links main.
2. Commit the change on it and push: git push -u origin fix/footer-links.
3. Open a pull request into main (gh pr create --base main).
4. Reviewers approve and the required checks pass.
5. Merge, at CatChow with Squash and merge (gh pr merge --squash --delete-branch).
6. The deploy puts the new main on the live site.
7. Check the change on the live site yourself.

The branch is deleted after the merge, and the next change starts again from the updated main. Anything unfinished waits on its own branch or, as you'll see, behind a switch.

At CatChow, Emma's copy, Daniel's free-delivery threshold and the checkout fix each took this path in about a week or less. Three short branches, three squash commits on main, each live within minutes of its merge.

“Merged” and “deployed” are two events. A merge changes main in the repository. A deploy takes that main, builds the site and puts it on the servers customers use. At CatChow the deploy is a GitHub Actions workflow, a job like build and test, except that it runs on main after every merge. The two are minutes apart, and the second follows the first on its own. In other teams they can be days or weeks apart.

So right after a merge, customers still see the old site, and they'll see the new one only if the deploy succeeds.

You can check 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. In a terminal, gh run list --branch main shows the latest workflow runs on main, deploys included.

Before you tell support something is live, do both: check production under Deployments, then take one look at the live site. The deploy tells you the code arrived; your own eyes tell you it works.

Sometimes the merge goes through and the deploy doesn't. Then main has the change and the site doesn't: customers keep seeing the previous version, the one the last successful deploy put there. Nothing is half-installed; the new version simply never arrived.

The team gets an alert and has two ways out:

• Fix forward: a small pull request that repairs whatever broke the deploy, merged quickly.
• Revert: undo the merge. The Revert button on a merged pull request opens a new pull request that removes exactly that change; in a terminal, git revert with the commit hash does the same.

Either way it jumps the queue. In GitHub flow main must stay deployable, and a broken main blocks everyone's next deploy, not just the one change.

For a PM, a failed deploy is one more reason to say “merged” and “live” separately. If a colleague asks about a merged change and the latest run under Deployments failed, the honest answer is “merged, not live yet, the team is on it”.

Building a whole feature on one branch and merging it once at the end sounds tidy. In practice it ends like feature/loyalty-points at CatChow: twelve commits ahead, 86 behind, untouched for five months.

Small pull requests on short-lived branches are safer for three reasons:

• Less drift. Every day a branch lives, main moves on without it. The further behind, the more conflicts, and the more surprises when old work meets new code.
• Better review. Forty changed lines take ten careful minutes. Two thousand wait for someone's free afternoon and then get skimmed.
• Precise undo. If one small change breaks something, a revert removes exactly that. Revert a huge one, and ten good changes leave with the bad one.

So small isn't about tidiness: it's less risk per merge. A rule of thumb many teams use is a branch that lives a few days and a pull request someone can review in one sitting. GitHub sets no size limit and gives small pull requests no shortcut through the review rules; the benefit is purely in how safely they ship.

You can spot a branch heading for trouble before it reaches review. Look at two numbers:

• When it was last updated. A branch nobody touched for weeks is either finished and forgotten, or stuck.
• How far behind main it is. The branches page shows “behind” and “ahead” counts for each branch. In a terminal, git rev-list --left-right --count main...feature/wishlist prints both: the first number is how many commits main has that the branch lacks (behind), the second how many the branch has that main lacks (ahead).

Old and far behind is the warning sign. On a commit graph it looks like a long lane that started high up while main kept collecting commits next to it. A branch that started from the latest main and holds one small commit is the opposite: little to review and nothing to catch up on.

The pull request tells the same story. If Files changed says 60 files for “a small tweak”, ask why. A friendly question early is cheaper than a painful review, or a risky merge, later.

A feature too big for one review doesn't need one big branch. Slice it into a series of small pull requests, each merged and deployed on its own, with the unfinished parts hidden behind one feature flag.

For loyalty points at CatChow, a slice plan might read:

1. Earn points on paid orders, stored but not shown anywhere.
2. Show the balance in the customer's account, behind the flag loyalty-points.
3. Spend points as a discount at checkout, behind the same flag.
4. Emma's page explaining the programme, behind the flag.

Each piece is reviewed in one sitting and goes live invisibly. The team switches the flag on for staff first and tries the whole thing on the real site. The feature is launched only on the day the flag goes on for every customer, and rolling back means switching it off.

The alternative, rebuilding everything on one long branch and merging it at the end, brings back every problem of feature/loyalty-points: drift, a review nobody can finish and an all-or-nothing launch.

A feature flag is a switch around a piece of the site. The code is in main and deployed, but customers see that piece only while the flag is on.

That solves a real timing problem. CatChow's autumn sale starts on Monday. Merge the sale banner by Emma, CatChow's content marketer, on Friday without a flag, and it announces a sale that hasn't started. Wait until Monday morning, and the review, merge and deploy all happen in a rush while customers are already arriving.

With a flag, Daniel wrapped the banner in a check for autumn-sale-banner, off by default. Emma's pull request #136 was reviewed and merged on Friday, and the deploy put the code on the site. On Saturday a customer opening the home page sees exactly what they saw before: the code is live, the flag is off. Nothing errors and nothing flickers.

So with flags, three states exist for one change: merged (in main), deployed (on the servers) and visible (switched on for customers). A merged pull request with its flag off means “done and hidden”, not “launched”.

At CatChow the flag switches live in a flag settings panel outside the repository. Turning one on or off needs no pull request, no review and no deploy, and it takes effect within seconds.

That changes how a launch works. On Monday at 8:00 Emma switches autumn-sale-banner on, and customers see the banner almost at once. If something looks wrong, she switches it off again, also without a deploy. Rolling back a flag is far faster than reverting a merge.

Flags also let a team merge unfinished work: the half-built part stays switched off, so main stays deployable while a feature grows in small pull requests. Many flag systems can switch a flag on for some people only, such as staff, before everyone.

The catch: every flag is an extra “if” in the code. Once a feature is on for good, someone should remove the flag in a small pull request, or the code fills up with forgotten switches nobody dares to touch. Put “remove the flag” on the plan from day one.

When a feature is built in small pull requests behind a flag, “where is it?” has two halves, and a PM reads both.

The pull request list shows how far the building has got. Give every piece the same label and filter by it: loyalty in the list, or gh pr list --label loyalty --state all in a terminal. Each row's state tells you its stage:

• Draft: still being written; it can't be merged yet.
• Open, “Review required”, checks passed: built and tested by the robots, waiting for a person's approval.
• Merged: in main and deployed, but with the flag off, invisible to customers.

The flag shows what customers see. Off: nobody sees it. On for staff: the team is testing on the real site. On for everyone: that's the launch.

So the launch is the moment the flag goes on for everyone, not the moment the last pull request is merged. That's why nobody should announce loyalty points just because loyalty code has been live since Tuesday.