правило

gitflow — правило для Cursor: что делает и как установить

Q: Как установить gitflow в Cursor?

Создайте файл `.cursor/rules/gitflow.mdc` в корне проекта и добавьте в него содержимое правила. Правило применяется ко всем файлам репозитория по маске `**/*`.

Q: Какой формат сообщений коммитов требует правило?

Используется шаблон `type(scope): description`. В качестве типа разрешены `feat`, `fix`, `docs`, `style`, `refactor`, `test` и `chore`.

Задаёт правила ветвления Gitflow, формат коммитов Conventional Commits и порядок релизов для ИИ-ассистента в Cursor.

Установить в Cursor · Вручную: положить файлы Все способы и платформы ↓

.cursor/rules/gitflow.mdc

Открыть на GitHub

Что делает gitflow

Правило инструктирует ассистента по структуре веток в репозитории. Ветки main и develop защищены. Прямые коммиты в них запрещены, поэтому рабочий код попадает туда только через слияния. Новые задачи создаются от develop по шаблону feature/[issue-id]-descriptive-name, а срочные исправления для продакшена ветвятся от main как hotfix/vX.Y.Z.

Для фиксации изменений задан формат сообщений type(scope): description с типами feat, fix, docs, style, refactor, test или chore. Версионирование опирается на Semantic Versioning. Слияние веток требует создания Pull Request с минимум одним одобрением. Проверки CI перед слиянием должны проходить успешно.

При завершении релиза или хотфикса ассистент обязан пометить коммит в main версионным тегом и отправить изменения обратно в develop. Без локальной ветки develop этот регламент сломается на первом же шаге.

Какие задачи решает

Запретить прямые коммиты в защищённые ветки main и develop
Унифицировать названия веток для задач, релизов и хотфиксов
Оформлять коммиты по стандарту Conventional Commits
Соблюдать регламент выпуска релизов с простановкой тегов версий

Примеры запросов агенту

Создай ветку для задачи 42 по авторизации пользователей
Подготовь релизную ветку для версии v1.2.0 из develop
Оформи коммит с исправлением ошибки валидации формы

Как установить gitflow

Вручную: положить файлы

.cursor/rules/gitflow.mdc

Во frontmatter: description, globs, alwaysApply

Вручную: положить файлы

.claude/rules/gitflow.md

Поле paths во frontmatter ограничивает файлы: globs из источника → paths

Вручную: положить файлы

.github/instructions/gitflow.instructions.md

Поле applyTo задаёт, к каким файлам применять: globs из источника → applyTo

Вручную: положить файлы

.devin/rules/gitflow.md

Вручную: положить файлы

.clinerules/gitflow.md

По шагам, с командами для каждой платформы: Cursor rules: файлы .mdc, четыре режима и замена .cursorrules

Вопросы о gitflow

Как установить gitflow в Cursor?

Создайте файл .cursor/rules/gitflow.mdc в корне проекта и добавьте в него содержимое правила. Правило применяется ко всем файлам репозитория по маске **/*.

Что делает правило gitflow?

Оно задаёт требования к ветвлению Gitflow, обязывает ассистента работать через ветки feature, release и hotfix, а также запрещает пушить код напрямую в main и develop.

Какой формат сообщений коммитов требует правило?

Используется шаблон type(scope): description. В качестве типа разрешены feat, fix, docs, style, refactor, test и chore.

Исходный текст

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

Из того же набора140