gitflow
via PatrickJS/awesome-cursorrules
Gitflow branching strategy with protected main/develop branches, feature/release/hotfix workflows, and semantic versioning.
What is gitflow?
Implements the Gitflow workflow model for structured git operations across teams. Use this rule to enforce branch naming conventions, protect production code, manage feature development, and coordinate releases through a multi-branch strategy with clear merge paths and version tagging.
- Defines main and develop branch protection rules with required PR reviews and status checks
- Enforces feature, release, and hotfix branch naming and merge workflows
- Requires semantic versioning (MAJOR.MINOR.PATCH) for release tagging
- Standardizes commit messages with type(scope): description format
- Mandates PR-based changes with minimum 1 approval and CI validation before merge
- Specifies release and hotfix processes including version bumping and back-merge to develop
Applies to
File patterns this rule matches.
Rule definition (reference)
Source of truth, from the repository.
Gitflow Workflow Rules
Main Branches
main (or master)
- Contains production-ready code
- Never commit directly to main
- Only accepts merges from:
- hotfix/* branches
- release/* branches
- Must be tagged with version number after each merge
develop
- Main development branch
- Contains latest delivered development changes
- Source branch for feature branches
- Never commit directly to develop
Supporting Branches
feature/*
- Branch from: develop
- Merge back into: develop
- Naming convention: feature/[issue-id]-descriptive-name
- Example: feature/123-user-authentication
- Must be up-to-date with develop before creating PR
- Delete after merge
release/*
- Branch from: develop
- Merge back into:
- main
- develop
- Naming convention: release/vX.Y.Z
- Example: release/v1.2.0
- Only bug fixes, documentation, and release-oriented tasks
- No new features
- Delete after merge
hotfix/*
- Branch from: main
- Merge back into:
- main
- develop
- Naming convention: hotfix/vX.Y.Z
- Example: hotfix/v1.2.1
- Only for urgent production fixes
- Delete after merge
Commit Messages
- Format:
type(scope): description - Types:
- feat: New feature
- fix: Bug fix
- docs: Documentation changes
- style: Formatting, missing semicolons, etc.
- refactor: Code refactoring
- test: Adding tests
- chore: Maintenance tasks
Version Control
Semantic Versioning
- MAJOR version for incompatible API changes
- MINOR version for backwards-compatible functionality
- PATCH version for backwards-compatible bug fixes
Pull Request Rules
- All changes must go through Pull Requests
- Required approvals: minimum 1
- CI checks must pass
- No direct commits to protected branches (main, develop)
- Branch must be up to date before merging
- Delete branch after merge
Branch Protection Rules
main & develop
- Require pull request reviews
- Require status checks to pass
- Require branches to be up to date
- Include administrators in restrictions
- No force pushes
- No deletions
Release Process
- Create release branch from develop
- Bump version numbers
- Fix any release-specific issues
- Create PR to main
- After merge to main:
- Tag release
- Merge back to develop
- Delete release branch
Hotfix Process
- Create hotfix branch from main
- Fix the issue
- Bump patch version
- Create PR to main
- After merge to main:
- Tag release
- Merge back to develop
- Delete hotfix branch
Related rules
Enforce disciplined AI coding practices: verify facts, make focused changes, avoid unnecessary commentary.
Clean code principles and best practices for readable, maintainable software development.
Idiomatic Go: explicit error handling, interface-based design, context-first concurrency.
AI pair programming assistant for Go backend development with scalability focus
Build REST APIs with Go's standard library ServeMux (Go 1.22+)