How to Use Git With Cursor AI

Cursor can help write and change code, but Git is what lets you see those changes in context and choose which ones to keep. This practical workflow shows how to prepare a project, review Cursor's edits, test them, and create a useful commit without accidentally discarding your own work.

1. Check your project before asking Cursor to edit

Open the project's repository in Cursor, then use its terminal or another terminal in the same folder to check your current branch and working tree:

git branch --show-current
git status --short

If you already have changes, identify which ones are yours before starting. Commit ready work, or leave it uncommitted and carefully distinguish it from later edits. Git does not automatically know which changes came from Cursor and which came from you.

2. Create a task branch and a clear checkpoint

For a focused feature or fix, create a branch from the starting point you intend to use:

git switch -c feature/add-search-filter

A branch separates this task from your main line of work, but it is not a backup for uncommitted changes. If you have a known-good starting state, make a small commit before asking Cursor to make larger edits. Confirm that the commit contains only changes you intended to save.

3. Give Cursor one bounded task at a time

A narrow request makes the resulting diff easier to review. Describe the files or behavior involved, what should remain unchanged, and which checks you expect. For example:

Update the search form to show a validation message for an empty query. Keep the existing API behavior unchanged. Do not commit or push. Tell me which files you changed and which test command I should run.

Review terminal commands before approving them. Be especially cautious with commands that remove files, discard edits, rewrite history, or send code to a remote repository. Do not include passwords, private keys, or active API tokens in a prompt.

4. Review the complete Git diff

When Cursor finishes, inspect the repository state before accepting the result. Cursor's source control view can help you browse file changes; Git commands give you a clear view of tracked and untracked work:

git status --short
git diff --stat
git diff
git diff --cached

Read the diff, not just its summary. Check for unrelated edits, accidental deletions, debug output, generated files, and hard-coded credentials. Untracked files do not appear in git diff; inspect them separately before staging. If you stage changes, review git diff --cached as the exact content prepared for commit.

5. Run checks, then commit only reviewed changes

Run the project's relevant tests, build, or lint command. If the result is wrong, ask Cursor for a specific correction and inspect the new diff again. When the change is correct, stage the intended files and check the staged snapshot:

git add path/to/file
git diff --cached
git commit -m "Add empty search query validation"

Replace the example path with the files you reviewed. If your own edits and Cursor's edits are mixed in the same file, use git add -p to stage selected changes, then review the staged diff. Push only when you intend to publish the commit and have confirmed the destination remote and branch.

Undo unwanted Cursor changes without losing other work

First inspect git status and git diff. To discard selected unstaged hunks, use git restore -p -- path/to/file. To discard all unstaged changes in one file, use git restore -- path/to/file only after confirming that none of those edits should be kept. These commands do not distinguish AI edits from your other uncommitted work.

If the unwanted change is already committed and shared, prefer git revert <commit-id> rather than rewriting shared history. See how to undo AI-generated changes safely for more recovery options.

Cursor and Git FAQ

Does Cursor replace Git?

No. Cursor can help edit code and show repository changes, while Git records versions, branches, and commits. Review and decide what to keep before committing.

Should Cursor commit or push code automatically?

Keep commits and pushes deliberate, especially while learning or working on a shared repository. Inspect the branch, destination, and staged diff before publishing changes.