Gitflow

Schlägt branch- und release-konforme Workflows nach dem Gitflow-Modell vor.

Original-Beschreibung der Autoren: Gitflow Workflow Rules. These rules should be applied when performing git operations.

Die Regel

---
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

So nutzt du sie

Die Regel kopieren (Button oben) oder als Datei herunterladen und im Projekt unter .cursor/rules/ ablegen — Cursor lädt sie beim nächsten Start automatisch. Ältere Cursor-Versionen lesen alternativ eine einzelne .cursorrules-Datei im Projektstamm; dort einfach den Regel-Text ohne den Kopfblock zwischen den ----Zeilen einfügen.

Der Regel-Text ist englisch — Cursor versteht ihn unabhängig von der Sprache, in der Sie mit dem Editor chatten.

Im Detail

Diese Regel schlägt der KI Workflows nach dem Gitflow-Branching-Modell vor: feature-Branches aus develop, release-Branches zur Stabilisierung vor einem Release und hotfix-Branches direkt aus main für dringende Korrekturen. Sie eignet sich für Projekte mit planbaren, versionierten Releases und mehreren parallelen Entwicklungssträngen, etwa Produkt-Software mit festen Release-Zyklen. Für Teams mit Continuous Deployment und häufigen, kleinen Releases ist Gitflow dagegen oft zu schwergewichtig – dort passen leichtere Modelle wie GitHub Flow oder Trunk-Based Development besser. Der Mehrwert der Regel liegt darin, dass die KI branch- und merge-Vorschläge macht, die zum gewählten Modell passen, statt beliebige Branch-Namen oder Merge-Strategien vorzuschlagen.

Praxis-Tipp

Fragen Sie z. B. „Welchen Branch-Typ brauche ich für dieses dringende Bugfix in Produktion?“, um direkt eine gitflow-konforme Hotfix-Anleitung zu erhalten.

Lizenz & Quelle

• Lizenz: CC0 1.0
• Quelle: PatrickJS/awesome-cursorrules (GitHub)

Lade …