gitflow
via PatrickJS/awesome-cursorrules
Enforce Gitflow branching strategy with protected main/develop branches and structured feature, release, and hotfix workflows.
What is gitflow?
Gitflow is a branching model that separates production code (main), development (develop), and temporary branches (feature/*, release/*, hotfix/*). Use this rule to enforce strict branch protection, naming conventions, and merge workflows across your team.
- Defines main and develop as protected branches accepting only merges from supporting branches
- Enforces feature branches from develop with naming convention feature/[issue-id]-descriptive-name
- Manages release branches (release/vX.Y.Z) for version bumps and production preparation
- Handles hotfix branches (hotfix/vX.Y.Z) for urgent production fixes merged to both main and develop
- Requires semantic versioning (MAJOR.MINOR.PATCH) and version tags on main after each merge
- Enforces pull request reviews, CI checks, and branch protection rules on main and 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
Senior full-stack TypeScript, React, Node.js guidance with clean architecture, testing, and WHY-oriented reasoning.
Quantitative factor research skills for designing, evaluating, and mining alpha factors in equities markets.
Android development with Jetpack Compose, clean architecture, and Material Design 3.
Angular development with Novo Elements UI library using standalone components.
Expert Angular 18 + TypeScript development with Jest, emphasizing clean code and performance.
Manage Kubernetes clusters, add-ons, stacks, and credentials via the Ankra CLI platform.