PlugSnatcher/.cursor/rules/git-workflow.mdc

192 lines
4.0 KiB
Plaintext

---
description:
globs:
alwaysApply: true
---
# Git Workflow for PlugSnatcher
This document outlines the Git workflow for PlugSnatcher development to maintain code quality and enable collaboration.
## Initial Setup
If you haven't already set up Git for the project:
```bash
# Initialize git repository
git init
# Add all current files
git add .
# Make the initial commit
git commit -m "Initial commit: PlugSnatcher basic structure"
# Create a remote repository on GitHub (if not already done)
# Then connect your local repository
git remote add origin https://git.spacetrainclubhouse.com/Space-Train-Clubhouse/PlugSnatcher.git
git push -u origin main
```
## Branch Structure
Maintain a structured branching strategy:
- `main`: Production-ready code
- `develop`: Main development branch
- Feature branches: `feature/feature-name`
- Bug fix branches: `fix/bug-description`
## Feature Development Workflow
1. **Create a Feature Branch**
Always branch from `develop` for new features:
```bash
git checkout develop
git pull
git checkout -b feature/plugin-scanner
```
2. **Make Regular Commits**
Commit changes with descriptive messages:
```bash
git add .
git commit -m "Add plugin metadata extraction functionality"
```
3. **Merge Back to Develop**
When the feature is complete:
```bash
git checkout develop
git pull
git merge feature/plugin-scanner
git push
```
## Bug Fix Workflow
1. **Create a Bug Fix Branch**
```bash
git checkout develop
git pull
git checkout -b fix/plugin-metadata-error
```
2. **Fix and Test**
Make the necessary changes and test thoroughly.
3. **Commit and Merge**
```bash
git add .
git commit -m "Fix plugin metadata extraction for malformed YML files"
git checkout develop
git pull
git merge fix/plugin-metadata-error
git push
```
## Versioning
Use semantic versioning (MAJOR.MINOR.PATCH):
- **MAJOR**: Incompatible API changes
- **MINOR**: New functionality in a backward-compatible manner
- **PATCH**: Backward-compatible bug fixes
When releasing a new version:
```bash
# Tag the release
git tag -a v0.1.0 -m "Initial beta release with plugin scanning"
git push origin v0.1.0
```
## Commit Message Guidelines
Write clear, concise commit messages following these guidelines:
- Use present tense ("Add feature" not "Added feature")
- Start with a verb
- Keep the first line under 50 characters
- Reference issues or tickets where applicable
- Include details in commit body if needed
Examples:
- "Add server type detection for Paper and Spigot"
- "Fix permission error in dialog plugin initialization"
- "Improve UI layout for plugin details modal"
## Pull Request Process
When working in a team:
1. Push your branch to GitHub
2. Create a Pull Request (PR) to the `develop` branch
3. Request code review from at least one team member
4. Address any comments or feedback
5. Merge PR once approved
## Git Best Practices for PlugSnatcher
1. **Handle Large Binary Files Properly**
Avoid committing large JAR files or test plugins to the repository. Use `.gitignore` to exclude these files.
2. **Handle Sensitive Information**
Never commit API keys, credentials, or sensitive configuration files. Use environment variables or configuration templates.
3. **Regular Backups**
Regularly push to the remote repository to maintain backups of your work.
## Git Ignore Configuration
Ensure your `.gitignore` file contains the following patterns:
```
# Node dependencies
node_modules/
npm-debug.log
yarn-debug.log
yarn-error.log
# Rust build artifacts
target/
# Environment files
.env
.env.local
.env.development.local
.env.test.local
.env.production.local
# Build outputs
dist/
build/
# OS-specific files
.DS_Store
Thumbs.db
# Test plugins
test-plugins/
*.jar
# IDE files
.idea/
.vscode/
*.swp
```
## Conclusion
Following these Git practices will help maintain code quality and enable collaboration as the PlugSnatcher project grows. Adjust these guidelines as needed based on team preferences and project requirements.