tevfikbgunes/gitflow-changesets-releases
Overview
This skill enforces a Gitflow workflow combined with Changesets for deterministic branching, versioning, and releases. It guides creation of feature, release, and hotfix branches, recommends manual changeset files for reliable changelog and version bumps, and shows the test gates to run before PRs and merges. The goal is clear, repeatable releases and predictable package versioning.
How this skill works
The skill outlines branch roles (main, develop, feat/*, fix/*, release/*, hotfix/*) and the merge flows between them to keep production and integration branches consistent. It describes creating manual .changeset files with a simple frontmatter indicating patch/minor/major, committing them, running changeset versioning, and then merging and tagging releases. It also prescribes running build and e2e tests before opening PRs or merging release/hotfix branches to main.
When to use it
- When creating or merging feature, release, or hotfix branches in a Gitflow workflow.
- When you want reliable, human-reviewed changelogs and deterministic version bumps.
- When writing conventional commits to keep commit history meaningful.
- Before opening PRs or performing a release to ensure tests pass (pnpm build && pnpm test:e2e).
- When you need to prepare or back-merge release and hotfix changes between main and develop.
Best practices
- Create changeset files manually with descriptive names for control and auditability.
- Use conventional commit style for code commits and imperative summaries in changesets.
- Run build and end-to-end tests before PRs and before merging release/hotfix branches.
- Version using pnpm changeset:version and commit package.json, CHANGELOG.md, and .changeset changes together.
- Always back-merge release or hotfix branches into develop after tagging main to avoid drift.
Example use cases
- Start a feature branch from develop, implement a feature, create a manual .changeset describing the change, test, and open a PR to develop.
- Cut a release branch from develop, run changeset:version, validate tests, merge to main, tag the release, then back-merge into develop.
- Create a hotfix branch from main for a critical production bug, add a patch changeset, bump version, test, merge to main, tag, and back-merge to develop.
- Run pnpm build and pnpm test:e2e locally before adding changesets to ensure the release pipeline will pass.
- Write concise changeset summaries (imperative voice) and include optional bullets for implementation details that belong in the changelog.
FAQ
Manual changesets give clearer editorial control, avoid interactive hangs on some systems, and produce predictable changelog entries.
When should I use major/minor/patch in a changeset?
Use major for breaking API changes, minor for new user-facing features, and patch for bug fixes or internal tweaks that don’t break consumers.