mirror of
https://github.com/mindverse/Second-Me.git
synced 2026-07-23 08:03:28 +00:00
201 lines
6.6 KiB
Markdown
201 lines
6.6 KiB
Markdown
# Contributing Guide
|
|
|
|
Second Me is an open and friendly community. We are dedicated to building a collaborative, inspiring, and exuberant open source community for our members. Everyone is more than welcome to join our community to get help and to contribute to Second Me.
|
|
|
|
The Second Me community welcomes various forms of contributions, including code, non-code contributions, documentation, and more.
|
|
|
|
## How to Contribute
|
|
|
|
| Contribution Type | Details |
|
|
|------------------|---------|
|
|
| Report a bug | You can file an issue to report a bug with Second Me |
|
|
| Contribute code | You can contribute your code by fixing a bug or implementing a feature |
|
|
| Code Review | If you are an active contributor or committer of Second Me, you can help us review pull requests |
|
|
| Documentation | You can contribute documentation changes by fixing a documentation bug or proposing new content |
|
|
|
|
## Before Contributing
|
|
* Sign [CLA of Mindverse](https://cla-assistant.io/mindverse/Second-Me)
|
|
|
|
## Here is a checklist to prepare and submit your PR (pull request).
|
|
* Create your own GitHub branch by forking Second Me
|
|
* Checkout [README](README.md) for how to deploy Second Me.
|
|
* Push changes to your personal fork.
|
|
* Create a PR with a detailed description, if commit messages do not express themselves.
|
|
* Submit PR for review and address all feedbacks.
|
|
* Wait for merging (done by committers).
|
|
|
|
## Branch Management Strategy
|
|
|
|
We follow a structured branching strategy to manage releases and contributions from both internal and external contributors.
|
|
|
|
### Branch Structure
|
|
|
|
```
|
|
master (stable version)
|
|
^
|
|
|
|
|
release/vX.Y.Z (release preparation branch)
|
|
^
|
|
|
|
|
develop (development integration branch)
|
|
^
|
|
|
|
|
feature/* (feature branches) / hotfix/* (hotfix branches)
|
|
```
|
|
|
|
## Development Workflow
|
|
|
|
```
|
|
hotfix/fix-bug
|
|
/ \
|
|
master ---------+---------+-----+--- ... --> Stable Version
|
|
\ /
|
|
\ /
|
|
release/v1.0 -----+-----------+--- ... --> Release Version
|
|
\ /
|
|
\ /
|
|
develop --------------+-----+---+--- ... --> Development Integration
|
|
/ /
|
|
/ /
|
|
feature/new-feature +----------- ... --> Feature Development (from master)
|
|
```
|
|
|
|
### Step 1: Fork and Clone (External Contributors Only)
|
|
If you're an external contributor, you need to fork the repository first:
|
|
|
|
1. Visit https://github.com/Mindverse/Second-Me
|
|
2. Click the "Fork" button in the top-right corner
|
|
3. Clone your fork to your local machine:
|
|
```bash
|
|
cd working_dir
|
|
# Replace USERNAME with your GitHub username
|
|
git clone git@github.com:USERNAME/Second-Me.git
|
|
cd Second-Me
|
|
```
|
|
|
|
4. Configure upstream remote:
|
|
```bash
|
|
# Add the upstream repository
|
|
git remote add upstream git@github.com:Mindverse/Second-Me.git
|
|
|
|
# Verify your remotes
|
|
git remote -v
|
|
```
|
|
|
|
### Step 2: Create a Feature Branch
|
|
All contributors should create feature branches from the `master` branch:
|
|
|
|
```bash
|
|
# First, ensure you have the latest changes
|
|
git fetch origin # or upstream if you're working with a fork
|
|
|
|
# Checkout the master branch
|
|
git checkout master
|
|
|
|
git pull
|
|
|
|
# Create your feature branch from master
|
|
git checkout -b feature/your-feature-name
|
|
```
|
|
|
|
### Step 3: Develop Your Feature
|
|
- Make changes in your feature branch
|
|
- Commit regularly with descriptive messages
|
|
- Follow the project's coding style
|
|
- Add tests if applicable
|
|
- Update documentation as needed
|
|
|
|
### Step 4: Commit Your Changes
|
|
```bash
|
|
# Add your changes
|
|
git add <filename>
|
|
# Or git add -A for all changes
|
|
|
|
# Commit with a clear message
|
|
git commit -m "feat: add new feature X"
|
|
```
|
|
|
|
### Step 5: Update Your Branch Before Submitting
|
|
Before submitting your PR, update your feature branch with the latest changes:
|
|
|
|
```bash
|
|
# Fetch latest changes
|
|
git fetch origin # or upstream if you're working with a fork
|
|
|
|
# Rebase your feature branch
|
|
git checkout feature/your-feature-name
|
|
git rebase origin/master # or upstream/master for forked repos
|
|
```
|
|
|
|
If you're an external contributor, you may need to push to your fork:
|
|
```bash
|
|
git push origin feature/your-feature-name
|
|
```
|
|
|
|
### Step 6: Create a Pull Request
|
|
1. Visit the repository (or your fork)
|
|
2. Click "Compare & Pull Request"
|
|
3. Select:
|
|
- Base repository: `Mindverse/Second-Me`
|
|
- Base branch: `develop` (all features and fixes go to develop first)
|
|
- Head repository: Your repository
|
|
- Compare branch: `feature/your-feature-name`
|
|
4. Fill in the PR template with:
|
|
- Clear description of your changes
|
|
- Any related issues
|
|
- Testing steps if applicable
|
|
- Target version if applicable
|
|
|
|
### Step 7: Address Review Feedback
|
|
- Maintainers will review your PR
|
|
- Address any feedback by making requested changes
|
|
- Push new commits to your feature branch
|
|
- Your PR will be updated automatically
|
|
|
|
### Step 8: PR Approval and Merge
|
|
- All checks must pass before merging
|
|
- Once approved, maintainers will merge your PR to the appropriate branch
|
|
- Your contribution will be included in the next release cycle
|
|
|
|
## Release Management
|
|
|
|
The following describes how releases are managed by project maintainers:
|
|
|
|
```
|
|
PR Merge Flow
|
|
|
|
|
master -------------------------+------ ... --> Stable Version
|
|
|
|
|
|
|
|
release/vX.Y.Z ---------------+------- ... --> Release Version
|
|
/ |
|
|
/ |
|
|
develop --------------------+--+------ ... --> Development Integration
|
|
^
|
|
|
|
|
feature branches --------------+
|
|
```
|
|
|
|
### Creating a Release
|
|
1. When `develop` branch contains all features planned for a release, a `release/vX.Y.Z` branch is created
|
|
2. Only bug fixes and release preparation commits are added to the release branch
|
|
3. After thorough testing, the release branch is merged to `master`
|
|
4. The release is tagged in `master` with the version number
|
|
|
|
### PR Merge Strategy
|
|
- All feature PRs are initially merged to the `develop` branch
|
|
- Critical bug fixes may be merged directly to the current `release` branch
|
|
- Maintainers are responsible for ensuring PRs are merged to the appropriate branch
|
|
|
|
### Hotfixes
|
|
1. For critical bugs in production, create a `hotfix/fix-description` branch from `master`
|
|
2. Fix the issue and create a PR targeting `master`
|
|
3. After approval, merge to both `master` and `develop` (and current `release` branch if exists)
|
|
|
|
## Tips for Successful Contributions
|
|
- Create focused, single-purpose PRs
|
|
- Follow the project's code style and conventions
|
|
- Write clear commit messages
|
|
- Keep your fork updated to avoid merge conflicts
|
|
- Be responsive during the review process
|
|
- Ask questions if anything is unclear
|