git-workflowlisted

## Constraints - Commit, PR, and merge conventions live in `@rules/git/general.mdc` — English `type(scope)` commits, lowercase, no trailing period, no push to `main`, small focused commits, `Closes #` issue linking, English PR titles, rebase-and-merge, `gh` CLI. This skill does NOT restate them. - Branch cleanup is owned by `@skills/cleanup-local-branches/SKILL.md`. Defer to it; do not duplicate. - PR merging is owned by `@skills/merge-github-pr/SKILL.md`. Defer to it; do not duplicate. - This skill covers only the complementary gaps below. ## Use when - Choosing or changing a branching strategy. - Deciding merge vs rebase for a specific situation. - Resolving a merge conflict. - Stashing work in progress. - Undoing a mistake (bad commit, wrong reset, accidental change). - Cutting a release and tagging a version. ## Branching strategies ### GitHub Flow (simple, recommended for most) `main` is always deployable. Branch from `main`, open a PR, merge after review and green CI, deploy. Best for SaaS and web apps with continuous deployment. ### Trunk-based (high-velocity) Everyone integrates into `main` via very short-lived branches (1–2 days). Incomplete work hides behind feature flags. CI must pass before merge. Needs strong CI/CD and discipline. ### GitFlow (release-cycle driven) `main` holds production code, `develop` is the integration branch, with `release/*` and `hotfix/*` branches. Heavyweight; only worth it for scheduled, regulated releases. | Strategy | Team size |