gitflow — Cursor rule: what it does, how to install
Configures Gitflow branching standards, Conventional Commits format, and release steps for the Cursor assistant.
.cursor/rules/gitflow.mdcWhat gitflow does
The rule guides Cursor on repository branch hygiene. Both main and develop branches remain protected. Direct commits are blocked. Feature branches must stem from develop using feature/[issue-id]-descriptive-name, while critical production bug fixes branch directly from main under hotfix/vX.Y.Z.
All commits must follow the type(scope): description structure with standard types such as feat, fix, or chore. Version numbering follows Semantic Versioning rules. Merging any branch requires an approved Pull Request and green CI status checks.
Finishing a release or hotfix branch requires tagging the version on main and back-merging into develop. Without an active develop branch in your Git repository, this workflow fails immediately.
What it helps with
- Block direct commits to protected
mainanddevelopbranches - Enforce naming conventions for feature, release, and hotfix branches
- Standardize commit messages with
type(scope): descriptionformat - Follow step-by-step release and hotfix lifecycles with semantic tags
Example prompts for the agent
- Create a feature branch for issue 42 about user profile editing
- Prepare a release branch for version v1.2.0 from develop
- Draft a commit message for the navigation bug fix
How to install gitflow
Manually: put the files in place
.cursor/rules/gitflow.mdcFrontmatter: description, globs, alwaysApply
Manually: put the files in place
.claude/rules/gitflow.mdThe paths frontmatter field limits the files: move globs from the source into paths
AGENTS.md
Codex reads AGENTS.md: paste the rule text there
Manually: put the files in place
.github/instructions/gitflow.instructions.mdThe applyTo field sets which files it applies to: move globs from the source into applyTo
Manually: put the files in place
.devin/rules/gitflow.mdManually: put the files in place
.clinerules/gitflow.mdStep by step, with commands for each platform: Cursor rules: .mdc files, four modes and what replaced .cursorrules
Questions about gitflow
How to install gitflow in Cursor?
Place the rule contents into .cursor/rules/gitflow.mdc in your project root. It targets all project files matching the **/* pattern.
What does the gitflow rule do?
It guides the assistant through Gitflow conventions. This covers branch lifecycles, structured commit messages, and strict Pull Request reviews before merging.
What branch naming schemes are enforced?
Features use feature/[issue-id]-descriptive-name, releases use release/vX.Y.Z, and hotfixes use hotfix/vX.Y.Z. Both release and hotfix branches must be deleted after merging.
Source text
gitflow.mdc · CC0-1.0
--- description: Gitflow Workflow Rules. These rules should be applied when performing git operations. globs: ["**/*"] alwaysApply: false --- # 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 1. All changes must go through Pull Requests 2. Required approvals: minimum 1 3. CI checks must pass 4. No direct commits to protected branches (main, develop) 5. Branch must be up to date before merging 6. 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 1. Create release branch from develop 2. Bump version numbers 3. Fix any release-specific issues 4. Create PR to main 5. After merge to main: - Tag release - Merge back to develop - Delete release branch ## Hotfix Process 1. Create hotfix branch from main 2. Fix the issue 3. Bump patch version 4. Create PR to main 5. After merge to main: - Tag release - Merge back to develop - Delete hotfix branch
© PatrickJS · CC0-1.0 · PatrickJS/awesome-cursorrules
