By name: "git-workflow" description: "Squad.SDK.NET branch model: dev -> preview -> main with changesets" domain: "version-control" confidence: "high" source: "team-decision"
Context
Squad.SDK.NET uses three long-lived branches:
| Branch | Purpose | Notes |
|---|---|---|
dev |
Integration branch for feature work | PRs target dev; releaseable SDK changes add .changeset files |
preview |
Release candidate branch | Promotion from dev applies changesets into csproj version + changelog |
main |
Stable released branch | Pushes trigger automatic tagging and NuGet/GitHub release creation |
Workflow for Issue Work
- Branch from
dev. - Do the work and add tests.
- If you changed releaseable SDK behavior under
src/Squad.SDK.NET/, add a.changeset/*.mdfile. - Open the PR against
dev. - After merge, maintainers promote
dev -> previewwithpromote.yml. - After preview validation passes, maintainers promote
preview -> main.
Changeset Rule
Releaseable SDK changes need a changeset:
---
"Squad.SDK.NET": minor
---
Add preview validation for release candidates.
Use:
patchfor backwards-compatible fixesminorfor backwards-compatible featuresmajorfor breaking API changes
Promotion Pipeline
dev -> preview: merge dev, apply changesets, bump csproj version, update changelog, clear applied changesetspreview -> main: merge validated preview into mainmain: createsv<Version>automatically and publishes the stable releasemain -> dev: the release commit is synced back into dev so new changesets start from the released baseline
Anti-Patterns
- ❌ Branching from
mainfor normal feature work - ❌ PRs targeting
maindirectly - ❌ Pushing manual release tags
- ❌ Skipping
.changesetfiles for releaseable SDK changes - ❌ Leaving pending changesets on
previewormain