BeamMP/BeamMP-Server
1
0
Fork 0
mirror of https://github.com/BeamMP/BeamMP-Server.git synced 2025-07-01 23:35:41 +00:00
Code Issues Packages Projects Releases Wiki Activity

update contributing

Browse Source
This commit is contained in:
Lion Kortlepel 2024-02-15 17:35:02 +01:00
parent ac8c386c61
commit 352a3aa536
No known key found for this signature in database
GPG Key ID: 4322FF2B4C71259B
1 changed files with 20 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
CONTRIBUTING.md
View File

@ -53,11 +53,28 @@ Do **NOT** pull with merge. This is the default git behavior for `git pull`, but
The only acceptable merge commits are those which actually merge functionally different branches into each other, for example for merging one feature branch into another. The only acceptable merge commits are those which actually merge functionally different branches into each other, for example for merging one feature branch into another.
## Workflow
### Making an issue and fixing it
1. Create an issue detailing the feature or bug.
2. Assign a milestone to the issue, or wait for a maintainer to add a milestone to your issue.
3. Fork the repository and base your work on the branch mentioned in the milestone attached to your issue (e.g. `v3.0.0 (develop)` -> `develop`).
4. Program your feature or bug fix.
5. Open a PR that references the issue by number in the format: `#12345`.
6. Someone will review your PR and merge it, or ask for changes.
### Fixing an existing issue
1. Fork the repository and base your work on the branch mentioned in the milestone attached to your issue (e.g. `v3.0.0 (develop)` -> `develop`).
2. Program your feature or bug fix.
3. Open a PR that references the issue by number in the format: `#12345`.
4. Someone will review your PR and merge it, or ask for changes.
## Branches ## Branches
### Which branch should I base my work on? - `minor`: Minor releases, like `v1.2.3` -> `v1.3.0` or `v1.2.3` -> `v1.2.4`.
- `develop`: Major releases, like `v1.2.3` -> `v2.0.0`, and larger feature/minor releases.
Each *feature* or *bug-fix* is implemented on a new Git branch, branched off of the branch it should be based on. The `master` branch is usually stable, so we don't do development on it. It is always a safe bet to branch off of `master`, but it may be more work to merge later. Branches to base your work on are usually branches like `rc-v3.3.0`, when the latest public version is `3.2.0`, for example. These can often be found in Pull-Requests on GitHub which are tagged `Release Candidate`.
## Unit tests & CI/CD ## Unit tests & CI/CD