Git Flow Release Process

VerifiedCaution

Complete guide for creating releases following Git Flow strategy with automated CI/CD. Handles semantic versioning, release branch creation, and automatic publishing.

Sby Skills Guide Bot
DevOpsIntermediate
12403/11/2026
Claude Code
#git-flow#release-management#semver#changelog#ci-cd

Recommended for

Automated summary

Walks through a Git Flow release: preparing develop, running local CI, choosing a semver number, creating the release/* branch, bumping the version, updating the CHANGELOG, opening the PR to main, then backmerging into develop.

Strengths

  • Covers the whole flow end to end, from checking develop to the backmerge into develop, with an explicit diagram
  • Ships an ordered checklist so each step can be verified as it is completed
  • States the project's hard rules: never push to main, deno.json version must match the tag, auto-release only fires from a release/* branch merge
  • Includes a complete worked example for a specific version (v1.8.0)
When to use it

Use it when preparing and shipping a new version of a Deno project that follows Git Flow with automated publishing to JSR.

When not to use it

Avoid it on projects that do not use Deno/JSR, Git Flow, or the described auto-release workflows.

Security analysis

Caution
Quality score90/100

The skill is a legitimate Git Flow release workflow and does not contain destructive, obfuscated, or exfiltrating instructions. However, it uses Bash, network-dependent git commands, and a project-local bump script, so it should be treated as a powerful-tool workflow requiring normal repository trust and permissions.

Findings
  • •Runs repository-provided script `bash scripts/bump_version.sh`, which executes repo-controlled code.
  • •Performs remote git operations (`git push`, merges) that modify shared branches.
How this analysis is made

Examples

Prepare a release
Prepare a release following Git Flow: check that develop is ready, run the CI locally, and propose the next semantic version based on the changes.
Bump to a specific version
Create a release/v1.8.0 branch from develop, bump the version in deno.json, update the CHANGELOG, and commit the bump.
Sync develop after release
The release was merged and published to JSR — backmerge main into develop and push it.

name: release description: Create a release following Git Flow strategy. Use when preparing a release, bumping version, creating release branch, or when user says "release", "bump version", "prepare release", "ship version". allowed-tools: Bash, Read, Edit

Release Process

This skill guides the release process following Git Flow with automated CI/CD.

Release Flow Overview

develop ──▶ release/v{X.Y.Z} ──PR──▶ main
   ▲                                   │
   │                                   ▼
   │                            (auto-release.yml)
   │                                   │
   │                                   ▼
   │                              tag: v{X.Y.Z}
   │                                   │
   │                                   ▼
   │                            (publish.yml)
   │                                   │
   │                                   ▼
   │                              JSR publish
   │                                   │
   └───────────── backmerge ◀──────────┘

Workflow

1. Ensure develop is ready

git checkout develop
git pull origin develop
git status

Verify all features for this release are merged.

2. Run full CI locally

deno task ci

All tests must pass before proceeding.

3. Determine version number

Follow semantic versioning:

  • MAJOR (X.0.0): Breaking changes
  • MINOR (0.X.0): New features, backward compatible
  • PATCH (0.0.X): Bug fixes only

Check current version:

jq -r '.version' deno.json

4. Create release branch

git checkout -b release/v{NEW_VERSION}

5. Bump version

Use the project's bump script:

bash scripts/bump_version.sh

Or manually update deno.json:

# Edit deno.json version field

6. Update CHANGELOG.md

Add release notes under new version heading.

7. Commit version bump

git add deno.json CHANGELOG.md
git commit -m "chore: bump version to {NEW_VERSION}"

8. Push and create PR to main

git push -u origin release/v{NEW_VERSION}

Create PR: release/v{NEW_VERSION} → main

Important: PR must be from release/* branch directly to main for auto-release to trigger.

9. Merge triggers automation

When PR to main is merged:

  1. auto-release.yml creates tag v{NEW_VERSION}
  2. publish.yml publishes to JSR

10. Sync develop with main

After release is published, backmerge main to develop:

git checkout develop
git pull origin develop
git merge origin/main
git push origin develop

This ensures develop has the version bump and CHANGELOG updates.

Checklist

  • [ ] All features merged to develop
  • [ ] deno task ci passes
  • [ ] Version number determined (semver)
  • [ ] Release branch created from develop
  • [ ] Version bumped in deno.json
  • [ ] CHANGELOG.md updated
  • [ ] PR to main created (from release/* branch)
  • [ ] PR merged → auto-release creates tag
  • [ ] Verify JSR publication
  • [ ] Backmerge main to develop

Example: Release v1.8.0

# Prepare
git checkout develop
git pull origin develop
deno task ci

# Create release
git checkout -b release/v1.8.0
bash scripts/bump_version.sh
# Edit CHANGELOG.md
git add deno.json CHANGELOG.md
git commit -m "chore: bump version to 1.8.0"
git push -u origin release/v1.8.0

# Create PR via GitHub
# release/v1.8.0 → main (triggers auto-release on merge)

# After merge and JSR publish, sync develop
git checkout develop
git pull origin develop
git merge origin/main
git push origin develop

Important Notes

  • Never push directly to main
  • Version in deno.json must match tag
  • Auto-release only triggers on release/* branch merge to main
  • JSR publish requires tag to be on main branch
Related skills