Version control and team collaboration in Cursor

Cursor’s agent handles the version-control work around a shared codebase: it drafts commit messages from the staged diff, resolves merge conflicts by reading both branches, writes pull request descriptions, and pre-reviews a teammate’s pull request. Git stays the record of truth, and tests plus git show --remerge-diff prove what the agent changed.

This page is for a developer who has Cursor installed and now works in a repository other people also push to. It is 5 p.m. on a Friday. You merge main into your feature branch before the release and hit a conflict in a file two colleagues changed this week. Their commit messages say “wip” and “fixes”, a teammate’s 600-line pull request has waited two days for review, and you do not have time to read either line by line.

What you get from agent-driven version control in Cursor

• A safe git baseline, so no agent action can cost you work you have not committed
• A commit-message prompt that follows your team’s convention and describes only what is staged
• A merge-conflict prompt that keeps both sides’ intent, plus two git commands that show exactly what the resolution changed
• A pull request prompt that produces a description a reviewer can act on
• A review prompt for someone else’s pull request that tells you where to look instead of reading every line
• A clear split between what you check, what CI checks, and what Bugbot checks

Team-wide configuration (shared project rules, MCP servers, and skills) is covered in team collaboration in Cursor. This page is about the daily git loop.

Set a safe git baseline before the agent touches history

Cursor’s agent runs git in its terminal like any other shell command, subject to the run mode you chose (Auto-review, Allowlist or Run Everything; Cursor’s docs, checked 2026-10-12). That makes it fast and also means a wrong git checkout --theirs . runs as readily as a right one. Put the safety net in place first.

1. Start every agent task from a clean tree. Commit or stash what you have; -u also stashes untracked files, so nothing new is left behind in the tree:

   git status --short
   git stash push -u -m "before agent task"

2. Work on a branch, never on main. For a task you want isolated from your own editor, use a Cursor worktree, which lets the agent work in a separate git checkout.

3. Write the git rules the agent must follow into your project rules (or into AGENTS.md, which Cursor also reads) so the agent has them in context: never force-push, never rewrite history that is already on the remote, never commit files matching .env*, and stop to ask before git reset --hard.

4. Keep pushing a human step for now. Let the agent commit locally, and push after you have looked at the checks described below.

Caution

git reflog is your undo for everything the agent does locally, because git records every move of HEAD there. It cannot recover changes that were never committed or stashed, which is why step 1 comes first.

Write commit messages from the staged diff

A commit message is the only context a teammate has when they meet your change in a conflict six months from now. The agent writes good ones when you tell it to read only the staged diff and to follow your convention. Without that instruction it tends to describe the whole working tree, including edits you did not stage.

Copy-paste prompt: commit message from the staged diff

Write a commit message for the changes that are staged right now. Read them with
`git diff --cached` only; ignore unstaged and untracked files.

Follow Conventional Commits (feat, fix, refactor, test, docs, chore) with a scope
taken from the top-level directory that changed. Subject line: imperative mood,
at most 72 characters. Body: explain WHY the change was needed and any behaviour
a reviewer should know about, not a list of files.

If the staged changes mix unrelated concerns, do not write one message. Tell me
how to split them into separate commits instead. Show me the message before you
run `git commit`.

Check the result in five seconds without reading the diff again: run git diff --cached --stat and confirm that every area the message mentions appears in the file list, and nothing in the list is missing from the message.

Resolve merge conflicts without losing either side

Generic “fix these conflicts” requests usually end with the agent picking one side and deleting the markers. The conflict disappears and so does a colleague’s change. The prompt below forces the agent to state each side’s intent first and to stop when the two are incompatible.

1. Start the merge and list the conflicted files:

   git merge origin/main
   git diff --name-only --diff-filter=U

2. Give the agent the prompt below with the file list pasted in.

3. When the agent has finished, run the test suite and the type check before you commit. A resolution that compiles but fails a test has dropped behaviour.

4. Commit the merge, then inspect only what the resolution did:

   git show --remerge-diff HEAD

   --remerge-diff needs Git 2.36 or later; check with git --version. This shows the difference between the conflicted state (with its <<<<<<< markers) and what was committed, so you review the decisions, not the whole files. For a rebase instead of a merge, git range-diff origin/main ORIG_HEAD HEAD compares your commits before and after the rebase.

Copy-paste prompt: resolve a merge conflict and keep both intents

These files have merge conflicts between my branch and origin/main:
<paste the output of git diff --name-only --diff-filter=U>

For each conflict hunk:
1. State in one line what each side changed and why. Use `git log -p` on the
   file for both branches if the intent is not obvious from the code.
2. Write a resolution that keeps BOTH intents where they are compatible. Never
   drop a side silently, and never use `git checkout --ours` or `--theirs` on a
   whole file.
3. If the two sides are incompatible (for example, both change the same
   function's return type), stop and ask me which behaviour should win.

When every file is resolved, run the test suite and the type check, report the
results, and list each hunk with the side(s) you kept. Do not commit.

The “stop and ask” line matters most. It is the difference between a merge you can trust and one where the agent removed a teammate’s fix to make the markers go away.

Open a pull request that a reviewer can act on

A pull request description written from the diff restates the diff. A useful one states the problem, the evidence that the fix works, and where the risk is. To let the agent open the pull request itself, connect the GitHub MCP server (setup in MCP setup for Cursor) or install the GitHub CLI (gh) and sign in once. The first snippet is the remote GitHub MCP server entry for Cursor (use a personal access token); the second authenticates gh:

~/.cursor/mcp.json

{ "mcpServers": { "github": {
  "url": "https://api.githubcopilot.com/mcp/",
  "headers": { "Authorization": "Bearer YOUR_GITHUB_PAT" } } } }

gh auth login

Copy-paste prompt: review-ready pull request description

Open a pull request from this branch into main. Base the description on the
commit messages in `git log origin/main..HEAD` and on the test results you get
by running the test suite now. The description must have these sections:

- Summary: one paragraph on the problem this solves and the approach, not a
  list of files.
- Evidence: the exact test and type-check commands you ran and their results.
  If anything failed, say so and do not open the pull request.
- How to verify: the steps a reviewer runs to see the new behaviour.
- Risk: anything that touches authentication, payments, database migrations,
  or a public API. Write "None identified" only if you checked all four.

Keep it under 250 words and link issue #234.

The Evidence section is what lets a reviewer trust the change without re-running everything. The full contract for agent pull requests, including acceptance results and a risk class, is in the evidence bundle.

Review a teammate’s pull request with the agent

The agent is most useful in review before you read any code: it builds the mental model, points at the risky hunks, and finds missing tests. You still decide whether to approve. Fetch the pull request into a local branch first so the agent works from real files:

git fetch origin pull/123/head:pr-123
git diff --stat origin/main...pr-123

Copy-paste prompt: pre-review someone else's pull request

Review the changes in `git diff origin/main...pr-123`. Do not edit any files.

1. In five sentences or fewer, explain what the change does and how data flows
   through it.
2. List the hunks I must read myself, ranked by risk: authentication and
   authorization, input validation, error handling that swallows exceptions,
   database queries, and concurrency. Give file and line for each.
3. List behaviour the change introduces that no test covers, and name the test
   you would add.
4. Check out pr-123 in a separate worktree, run the test suite there, and
   report the result.

Do not comment on style that our linter already enforces.

Read the hunks from step 2 and the missing tests from step 3, then approve or request changes. For a deeper review workflow, including one pass per concern and large refactors, see code review with Cursor.

Where does Bugbot fit in the review loop?

Bugbot is Cursor’s pull request reviewer: it “reviews pull requests and identifies bugs, security issues, and code quality problems” (cursor.com/docs/bugbot, checked 2026-08-28). It runs on the forge after you push, so it catches what your local checks missed rather than replacing them. Cursor’s help pages, as summarised on 2026-08-28 and not re-verified since, also describe a .cursor/BUGBOT.md file for project-specific review guidance and a bugbot run comment that re-runs a review on demand. Setup, learned rules, and Autofix are covered on the Bugbot page.

To work through Bugbot’s findings in one pass, give the agent the comments rather than retyping them:

Copy-paste prompt: work through Bugbot findings

Read the inline review comments on pull request #123 with
`gh api --paginate repos/{owner}/{repo}/pulls/123/comments`, and the review
summaries with `gh pr view 123 --comments`. Bugbot posts its findings inline, so
the first command is the one that returns them.
For each Bugbot finding: fix it if it is correct, or explain in one line why it
is a false positive. Run the tests after all fixes and show me the diff. Do not
push.

Caution

If you make the Bugbot check required in branch protection, confirm what status it reports when it finds issues. A required check that passes with open findings runs on every pull request and blocks none of them.

Split parallel work across worktrees and cloud agents

Two unrelated tasks do not have to wait for each other. A local worktree gives each agent its own checkout on your machine. A cloud agent runs in an isolated VM in the cloud and can be started from the editor or by an Automation (for example, on a new Slack message). Either way, each task ends on its own branch, ready for a pull request, and goes through the same checks. Keep the tasks independent: two agents editing the same module produce the merge conflict from the previous section, and you resolve it later with less context. Worktree setup and parallel runs are covered in checkpoints and branching.

How do you prove the agent’s git work is correct?

You do not re-read every line. Each artifact has a check that answers one question, and a named person who signs off.

Artifact	Check	Signs off
Commit message	git diff --cached --stat matches the areas the message names	Author
Merge resolution	Tests and type check pass, then git show --remerge-diff HEAD shows each decision	Author
Rebase	git range-diff origin/main ORIG_HEAD HEAD shows no unintended change to your commits	Author
Pull request	CI green, and the Evidence section lists the commands run and their results	Author, then reviewer
Review of a teammate’s pull request	You read the risk-ranked hunks and the missing-test list	Human reviewer approves
Post-push review	Bugbot findings fixed or explained	Author

When agent-driven git work goes wrong

• The merge “resolved” by dropping a teammate’s change. Before you commit, run git merge --abort and start again with the conflict prompt above. After you commit but before you push, git reset --hard ORIG_HEAD returns you to the pre-merge state; this discards the merge commit, so check git log -1 ORIG_HEAD first.
• The agent committed something you did not want. Find the last good entry with git reflog, then git reset --soft HEAD@{1} (or the SHA from the reflog) to undo the commits and keep the changes staged.
• The commit message describes unstaged work. The agent read git diff instead of git diff --cached. Re-run the commit-message prompt, which names the command explicitly.
• A secret or .env file reached a commit. If it is not pushed, remove it with git rm --cached .env, add the pattern to .gitignore, and amend the commit. If it was pushed, rotate the secret first; rewriting history does not remove it from clones and forks.
• The agent force-pushed a shared branch. Anyone who still has the old tip can restore it. Ask them to find it in their git reflog as <old-sha>, then push it back with git push --force-with-lease=<branch>:<bad-sha> origin <old-sha>:<branch>, where <bad-sha> is the tip the agent pushed. The lease makes the push fail if anyone has pushed since. Then add “never force-push” to your project rules, and protect the branch on the forge.
• The agent ignores your git rules. Confirm the rules actually load in a session before you rely on them, and remember that rules apply to Agent only, not to Tab completion, Inline Edit or Bugbot PR reviews (Cursor help, checked 2026-10-12). The check is in team collaboration in Cursor.

Where to go next with Cursor team workflows

Team collaboration in Cursor Commit shared rules, MCP config, and skills so every teammate's agent behaves the same way.

Code review with Cursor Self-review before the pull request, one pass per concern, and review rules for your team.

Checkpoints and branching Worktrees, parallel runs, and a commit cadence for agent work.

The evidence bundle What an agent's pull request must prove before a human reviews it.

Version control in Claude Code The same git loop from the terminal, for teams that also use Claude Code.

Codex GitHub integration How Codex connects to GitHub for pull requests and review.