---
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.