cherry-studio/docs/branching-strategy.md

# 🌿 Branching Strategy

Cherry Studio follows a structured branching strategy to maintain code quality and streamline the development process:

## Main Branches

- `main`: Production-ready branch containing stable releases

  - All code here is thoroughly tested and ready for production
  - Direct commits are not allowed - changes must come through pull requests
  - Each merge to main represents a new release

- `develop` (default): Primary development branch
  - Contains the latest delivered development changes for the next release
  - Relatively stable but may contain features in progress
  - This is the default branch for development

## Contributing Branches

When contributing to Cherry Studio, please follow these guidelines:

1. **For bug fixes:**

   - Create a branch from `develop`
   - Name format: `fix/issue-number-brief-description`
   - Submit pull request back to `develop`

2. **For new features:**

   - Create a branch from `develop`
   - Name format: `feature/issue-number-brief-description`
   - Submit pull request back to `develop`

3. **For documentation:**

   - Create a branch from `develop`
   - Name format: `docs/brief-description`
   - Submit pull request back to `develop`

4. **For critical hotfixes:**
   - Create a branch from `main`
   - Name format: `hotfix/issue-number-brief-description`
   - Submit pull request to both `main` and `develop`

## Pull Request Guidelines

- Always create pull requests against the `develop` branch unless fixing a critical production issue
- Ensure your branch is up to date with the latest `develop` changes before submitting
- Include relevant issue numbers in your PR description
- Make sure all tests pass and code meets our quality standards
- Critical hotfixes may be submitted against `main` but must also be merged into `develop`
- Add a photo to show what is different if you add a new feature or modify a component in the UI.