Branching strategy
Your team's agreed rules for how branches get created, named, merged, and released, so git doesn't turn into a free-for-all.
See it
What it is
A branching strategy is the written agreement about where code lives between 'I started it' and 'users have it': which branches exist, what each one means, how long they live, and what has to be true before a merge. The point is not the diagram. It is that nobody has to guess whether main is deployable.
The named ones, roughly by weight. GitHub Flow: main plus short feature branches, deploy from main, which suits web apps that ship continuously. Trunk-based: the same idea taken further, with daily merges and feature flags. Git Flow: main, develop, feature, release, and hotfix branches, which fits versioned or installed software with real release windows and is heavy overkill for a site that deploys ten times a day. Release branches: cut from main, stabilized, hotfixes cherry-picked back.
Pick by how you release, not by what sounds professional. The failure mode is a strategy nobody enforces: adopt Git Flow, quietly stop using develop, and now you have two stale mains. Encode the rules in branch protection and required status checks so the strategy is machinery rather than folklore, and remember that long-lived branches are how merge conflicts get expensive.
Ask AI for it
Propose a branching strategy for this repo and write it as a short CONTRIBUTING.md section. Base it on GitHub Flow: main is always deployable, short-lived branches named type/short-description (feat, fix, chore), squash merge, delete branch on merge, and no release branch by default, because GitHub Flow deploys from main and does not normally have one. Specify how hotfixes work and which commit message convention we follow. Then check whether this repo ships something users stay on for a while (a published package, an installed desktop app, an app-store build, a supported old version). If it does, define the exact exceptional conditions that justify cutting a short-lived release branch, how long it may live, and how fixes get merged back into main; if it does not, say so and leave release branches out entirely. Then give me the exact GitHub branch protection configuration to enforce it (required status checks, required reviews, no force push, linear history) and a table comparing this to Git Flow so I can see what I am giving up.