Cursor Rules for Git: Commits, Branches, and Reviews

Cursor rules for Git tell the AI assistant what commit message format to use, which branch naming pattern the team follows, and what it is not allowed to push or force-merge on its own. Without these rules, an assistant will make reasonable guesses — usually wrong enough to produce a cleanup commit before the real review.

The rules encode what the team has decided. The reasoning behind each decision belongs in fenbs as Decisions and rules, where it stays visible to every assistant and every team member, not just the person who last edited the .cursorrules file.

What Git rules should cover

• Commit message format: conventional commits, ticket prefix, character limit, imperative mood, or your own pattern.
• Branch naming: feature/, fix/, chore/ prefixes, or a ticket-number format.
• What the AI may not do without asking: pushing to main, force-pushing, amending published commits, tagging.
• How to handle merge conflicts: rebase or merge, and whether the AI should resolve them automatically.
• Whether to run tests or checks before committing, and which command to use.

A starting template

# Git workflow

## Commit messages
- Use conventional commits: <type>(<scope>): <short description>
- Types: feat, fix, docs, refactor, test, chore
- Keep the subject line under 72 characters.
- Do not end the subject line with a period.
- Add a blank line between subject and body when a body is needed.

## Branches
- Branch names follow the pattern: <type>/<short-slug>
- Create branches from main unless told otherwise.

## What to ask before doing
- Do not push to main or any protected branch.
- Do not force-push any branch.
- Do not amend a commit that has already been pushed.
- Ask before resolving a merge conflict automatically.

## Before committing
- Run [TEST_COMMAND] and confirm it passes.
- Do not commit generated files or build output.

Adapting to your team's conventions

Replace [TEST_COMMAND] with the real command from your project. If your team uses a ticket prefix like PROJECT-123 in commit messages, add that to the format line. If your protected branches are named differently from main, list them explicitly.

Avoid writing rules that repeat what your linter or pre-commit hook already enforces. A rule the assistant cannot verify independently creates confusion. Rules about what to run, what not to push, and how to format messages are the most reliable. See Cursor rules examples for patterns that hold up in practice.

Pre-commit hooks and Cursor rules

Pre-commit hooks and Cursor rules are complementary, not redundant. A hook enforces a rule mechanically at commit time; a Cursor rule tells the assistant what to do before it gets to the commit step. Together they create two checkpoints: the assistant does not try to commit something it knows the hook will reject, and the hook catches anything the assistant missed.

If your project uses a tool like Husky or lefthook to manage pre-commit hooks, list the hooks in the rules file so the assistant knows what will run. A rule like "a pre-commit hook runs npm run lint and npm run test:unit" tells the assistant which checks it can skip running manually (because the hook covers them) and which checks it still needs to run separately.

Commit scope and size

If your team has a convention about commit size or scope — one logical change per commit, or a specific way to handle work-in-progress commits — add that to the rules. An assistant left to decide on its own will either make one large commit that touches everything or many small commits that split related changes. Neither is wrong in general, but either can be wrong for your project's specific review process.

For projects that use a ticket-driven workflow, a rule about including the ticket number in every commit message saves review time. State the exact format: feat(PROJECT-123): short description or [PROJECT-123] short description depending on your convention. An assistant that learns the format from one commit will apply it going forward.

History: why the decisions behind the rules matter

A rule that says "do not push to main" is clear enough. A rule that says "do not push to main because releases are cut from release/ branches and main is the merge target for hotfixes" gives an assistant the context to ask the right question when something unusual happens.

Those explanations are too long for a rules file. They belong in fenbs as Decisions, linked to the tasks they affect. When an assistant reads the project context before starting, it reads the decision, its reason, and the current task — not just the constraint in isolation.

How to manage Cursor Git rules with fenbs

1. Create a free account and add your project to fenbs. Record your Git conventions as Decisions and rules: commit format, branch naming, and any push restrictions.
2. Add the rules template above to your project's .cursor/rules/ directory, replacing the placeholders with your real commands and branch names.
3. Connect Cursor to fenbs over MCP from Integrations. Ask the assistant to read the project context at the start of each session so it knows the current decisions.
4. When your team agrees to change a Git convention, update the Decision in fenbs and update the rules file. The History in fenbs records when the change was made and why.

What to watch for

Git rules that contradict each other are the most common failure mode. If you tell an assistant to always run tests before committing and also to commit partial work as checkpoints, those instructions conflict. Be explicit about which takes priority or keep them in separate scoped rules files.

Rules about what an assistant may not do need to match your repository's actual branch protection settings. If main is not a protected branch in your hosting provider, the rule alone will not stop a push. Use both the rule and the protection setting. The Cursor CLI guide covers how Cursor interacts with your terminal for commands like these.