Best Practices for Version Control in Cursor: Focus on Composer Feature

General
1

I’m seeking guidance on best practices for version control when using Cursor, particularly in relation to the Composer feature. My main questions are:

  1. What are the recommended approaches for managing versions in Cursor projects, specifically when using the Composer feature?
  2. How does Cursor’s internal versioning system work within the Composer? I’m particularly interested in understanding the process of reverting to previous versions of the code. Given that the Composer feature often involves rapid iterations and AI-assisted code generation, what strategies do experienced users employ to keep track of these changes effectively?
  3. Is it possible (and advisable) to integrate Cursor’s internal versioning, especially for Composer-generated content, with Git? If so, how can we best combine these two version control methods?
  4. Are there any specific considerations or best practices for version control when collaborating on projects that heavily utilize the Composer feature?

I’d appreciate insights from experienced Cursor users on how they manage their project versions, especially in projects that make extensive use of the Composer. Any tips, tutorials, or resources on this topic would be extremely helpful. Thank you in advance for your assistance!

3 Likes
2

This thread is a couple months old, but after getting burned by Composer last night and losing a big chunk of my code due to recklessly accepting changes, I am rethinking version control. For whatever reason, I was not able to recover what I lost using the new checkpoint feature in Composer which is great (thank Cursor team!).

I am curious to hear what others best practices are for version control - especially when editing files directly on a server. I have started committing to git when I reach stable points in the code, so I at least can rollback to a stable point if I have a loss like I did yesterday or have elements of my code that was removed to speed up restoration. Perhaps there is some git/vscode magic that might automate this.

3

@cursortesting @ team.
pls fix cursor.

far too often now it’s getting lazy (sonnet 3.6) & will insert a ‘// rest of code remains unchanged’
& then proceeds to delete most of the code.
as with devgrinder above I’ve lost large chunks of code multiple times (thank the god of your choice for git)
but now it’s slow going checking every change.

can this be tuned out?

4

I’d probably try to add “don’t be lazy” prompt in my cursor rules as well as just committing more (at least staging changes) often. Then you can as you say just roll back to a good point in time.

Do you have any suggestions on how you’d like it to work?

1 Like
5

thanks for the quick reply.
yeah I have started doing that & backing up more often.
I just don’t think the composer should ever be allowed to use the phrase ‘rest of your code remains the same’. It’s 100% fine when claude does that in chat… but the result of it ‘thinking’ this in composer is to delete large chunks of code.
no idea how you solve that
but would love it if you can.

BTW, freaking LOVE what you’ve built. Been evangelising it since I started using it at Xmas. You’re changing the world. Keep going & thank you.

6

Totally hear you! Will look into this and see what we could do.

And thanks! Always eager to get more feedback like this!

1 Like