Picking How Your Team Actually Works

Squash or merge. Rebase or not. One long-lived branch or several. Feature flags or feature branches. These look like separate arguments and they are one argument, asked in different words: how long should work live away from main?

The trade-off is genuine and it does not have a universal answer.

The simplest model that supports review, and by a wide margin the most common on GitHub. One permanent branch — main, always deployable — and short-lived branches off it.

1. 1

   Branch from main

   Named for what it does. fix/login-redirect, feat/csv-export.

2. 2

   Commit and push

   Push early. The branch is backed up and visible, and CI starts running.

3. 3

   Open a pull request

   Draft while it is in progress. Discussion happens here, not in chat.

4. 4

   Review and iterate

   Checks run on every push. Comments are addressed by pushing more commits.

5. 5

   Merge and delete

   Squash into main, delete the branch. main is deployable again immediately.

If your team has not chosen deliberately, this is the one to start with. It is what GitHub itself is designed around, which is why every default — the pull request form, the merge button, auto-delete branches — fits it without configuration.

The same shape, pushed to its logical end: branches live hours rather than days, and anything that cannot be finished in a day is merged incomplete but switched off.

// The new checkout is on main, merged, tested — and dark.if (flags.newCheckout) {  return <NewCheckout />;}return <LegacyCheckout />;

A feature flag separates deploying from releasing. The code ships to production continuously and stays invisible until a runtime switch enables it — for the team, then for one per cent of users, then for everybody. Turning something off becomes a setting change rather than a revert and a deploy.

Git Flow, described by Vincent Driessen in 2010, is the elaborate one: two permanent branches and three kinds of temporary branch.

It is a genuinely good design for the problem it was built for: versioned software that ships on a schedule, where several released versions are supported at once, and where a release is a thing that gets prepared. Desktop applications, libraries, firmware, anything with a version number a customer says out loud.

It is a poor fit for a website deployed continuously — which is most of what people build now, and which is why the author added a note to his own post saying so. The develop branch, in particular, is pure overhead when main is deployed the moment something merges.

Git enforces none of this. Every one of these models is the same commands in a different order, and the tool will let you do any of them, or none, or a different one each week.

What makes a workflow real is the part written down and the part configured. Both, and the same one.

# Tag and release, whichever workflow you chose$ git tag -a v1.4.0 -m "CSV quoting, faster export"$ git push origin v1.4.0$ gh release create v1.4.0 --generate-notes

--generate-notes writes the release notes from the pull requests merged since the last tag, which is the strongest practical argument for the habits in this whole track: good pull request titles, linked issues, and one logical change per merge turn into a changelog you did not have to write.

Start with GitHub Flow. Add branch protection. Keep branches small. Change something only when you can name the problem it fixes — that rule alone puts you ahead of most teams, and it is the same rule as every other chapter here: know what the tool is doing, and choose on purpose.