Best Practice for Cursor Commits

How To
1

The Problem

  • Things can go wrong quickly or you find yourself in a dead end.
  • I want to be in the practice of commiting as often as possible when things are in a stable state.
  • I forget to do this a lot and end up in bother. -
  • I also don’t trust checkpoints completely yet.

My Solution

My solution was adding this line below to the cursor rules file or the system cursor rules. This does two things 1. Reminds me to check if it’s a good time to commit 2. Gives me an actual summary commit message which saves time

“When you finish applying changes, the last line of the message should “Don’t forget to commit!” and give me a commit command as well.”

And this is what I get

image
image555×154 6.37 KB

I also use this in the rules file to get more succinct commit messages:

Always prefix Commit Messages in the following way. No exceptions

“Feat(component): add new component”
“Fix(api): fix api error”
“Docs(readme): update readme”
“Refactor(utils): refactor utils”
“Style(tailwind): add new tailwind class”
“Test(unit): add unit test”
“Chore(deps): update dependencies”

Does anyone else have some good practices?

1 Like
2

@robshox Thanks for bringing this up! I noticed this at 18:05 in your recent video:

My take-away there was

you can create a [[CursorAI/Project Rules]] entry that includes a git commit command, which is both faster and more customizable than using the built-in UI, but you need to be careful when staging files for a commit

One of the things I like about this approach is that it enables one to utilize Conventional Commits in a way that’s a bit more likely to be consistent than when using the auto-generated commit message.

Also, as you noted in your video, it’s likely to be faster to utilize commits “in the flow” of the Composer agent’s work, rather than to have to activate the source control panel and utilize its features.

One thing that I am still unsure of is how best to stage files for the commit. As a software developer I rarely use git commit -A and instead maintain a bit of rigor about what files I stage; sometimes I may have many files that were unassociated with the current commit message that I want to leave for later.

I wonder if there’s a way to get “human in the loop” for this without having to 1.) stage each file individually or 2.) utilize the brute force stage everything approach. Perhaps we might ask it to have separate git add commands for each folder of changes, which would give us a chance to review it …?

3

That’s a really good approach. Personally I go between add all and the stage carefully approach. Probably more of the latter. Not sure how you’d apply it folded by folder, maybe globing. But I also find cursors adherence to the rules sketchy in this case so it could be inconsistent

4

Super good, however, You should also try the following married into your directive:

Create a development_diary.json and a diary.rmd and catalogue your thoughts appropriately for the project. Add as many tables about schema, dev, UX as appropriate. Always update the projects scope and structure. Include mermaids and export to SVGs. /scripts/svg/

Verbose logging in /logs

You might find it amazing.