docs: Enhance commit and PR guidelines #9
Conversation
- Add commit-changes-rules with proper commit format guidelines - Add pull-request-rules with PR creation guidelines - Remove conventional-commits.mdc rule - Update .gitignore file
There was a problem hiding this comment.
Copilot reviewed 1 out of 4 changed files in this pull request and generated no comments.
Files not reviewed (3)
- .cursor/rules/commit-changes-rules.mdc: Language not supported
- .cursor/rules/conventional-commits.mdc: Language not supported
- .cursor/rules/pull-request-rules.mdc: Language not supported
## Walkthrough
This update introduces new documentation for standardized commit and pull request practices, while removing a previous rule enforcing Conventional Commits. The `.gitignore` file is modified by removing ignore patterns for the `mcp` executable and its config file. The new documents provide detailed, step-by-step guidelines for analyzing, formatting, and submitting both commits and pull requests, specifying message formats and processes. The prior Conventional Commits rule is deleted, and there are no changes to code or exported entities.
## Changes
| File(s) | Change Summary |
|------------------------------------------------|-----------------------------------------------------------------------------------------------------------------|
| `.cursor/rules/commit-changes-rules.mdc` | Added new documentation defining structured commit and push guidelines, including commit message formatting and examples. |
| `.cursor/rules/pull-request-rules.mdc` | Added new documentation specifying pull request creation and update rules, including PR title and body formatting. |
| `.cursor/rules/conventional-commits.mdc` | Deleted file that previously enforced the Conventional Commit message format with detailed specification and examples. |
| `.gitignore` | Removed ignore rules for `mcp` executable and `mcp-config.json`, allowing these files to be tracked. |
## Suggested reviewers
- anatolyshipitzPossibly related PRs
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
🔍 Vulnerabilities of
|
| digest | sha256:fc62a055971c7cb4f3836504e47654e4aecc7441863c992176f16c31f61e5084 |
| vulnerabilities |     |
| platform | linux/amd64 |
| size | 243 MB |
| packages | 1628 |
📦 Base Image node:20-alpine
| also known as |
|
| digest | sha256:37a5a350292926f98d48de9af160b0a3f7fcb141566117ee452742739500a5bd |
| vulnerabilities |   |
Description
| ||||||||||||
Description
| ||||||||||||
Description
| ||||||||||||
Description
| ||||||||||||
Description
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (5)
.gitignore (1)
21-21: Verify.cursordirectory ignore policy
Removing the previous.cursor/*ignore patterns means all files under.cursor, including potential temporary or generated files, will now be tracked. Please confirm no other artifacts need to remain ignored. Consider reintroducing a whitelist like:.cursor/* !.cursor/rules/**to only include the new rules documents.
.cursor/rules/commit-changes-rules.mdc (3)
1-5: Fix typo in frontmatter description
Thedescriptionfield reads “Rules for commiting and pushing changes”; correct the spelling to “committing.” Also review theglobsandalwaysApplyfields—if they aren’t used, consider clarifying or removing them.
28-35: Specify language for code fences
The example commit message is helpful; consider adding a language label to the backticks (e.g.,textormarkdown) for better syntax highlighting in editors that support MDX.
52-56: Clarify multiple bullet points with-mflags
Method 2 shows a single-musage for the first bullet. If committing multiple bullets, the example should demonstrate chaining-mflags (e.g.,git commit -m "Title" -m "- point1" -m "- point2")..cursor/rules/pull-request-rules.mdc (1)
1-9: Refine frontmatter and header metadata
The YAML frontmatter hasdescription, emptyglobs, andalwaysApply: false, followed by manualRule Name:under the heading. Consider consolidating rule metadata into the frontmatter (e.g., addname: pull-request-rules) or removing unused fields for consistency.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.cursor/rules/commit-changes-rules.mdc(1 hunks).cursor/rules/conventional-commits.mdc(0 hunks).cursor/rules/pull-request-rules.mdc(1 hunks).gitignore(1 hunks)
💤 Files with no reviewable changes (1)
- .cursor/rules/conventional-commits.mdc
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Docker Security Scanning (n8n, Dockerfile.n8n, n8n-test:latest)
- GitHub Check: Service Availability Check
🔇 Additional comments (10)
.cursor/rules/commit-changes-rules.mdc (4)
10-14: Approve Analysis Process section
The steps for runninggit --no-pager statusandgit --no-pager diffare clear and actionable.
15-20: Approve Commit Process section
The outlined commit workflow (stage, message, commit, push) is concise and covers best practices.
21-27: Approve Commit Message Format
The format rules (title, blank line, bullet list) are clearly specified and easy to follow.
36-50: Approve Git Command Format – Method 1
Using separateechocommands to build a commit message file is explicit and avoids tokenization issues..cursor/rules/pull-request-rules.mdc (6)
12-16: Approve Analysis Process section
The steps for status, diff, and analysis provide clear guidance before opening a PR.
17-23: Approve Pull Request Types list
Enumeratingfix,feat,BREAKING CHANGE, and other prefixes aligns well with semantic versioning.
26-30: Approve Specification Details
The rules for title prefix, optional scope, exclamation mark, and colon are clearly described.
31-37: Approve Pull Request Format
The body structure (bullets then rationale) and prohibition on repeating the title are well-defined.
50-59: Approve PR Description Formatting
Guidance on bullet formatting, CLI usage, and previewing in GitHub is practical and thorough.
60-65: Approve Process section
The final process steps—analyze, title, create/update PR, request review—are concise and complete.
- Update example in pull-request-rules to include 'feat:' type prefix in the title
|
These changes improve the development workflow by providing clearer guidance for both commit messages and pull request creation.